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Preface 


This  revised  Introduction  to  DECnet  reflects  capabilities  of  the  following  new 
products: 

•  DECnet-VAX  Version  3.1  (VMS  V3.4) 

•  DECnet-RSX   (RSX-llM   and  RSX-llS  Version  4.0;  RSX-llM-PLUS 
Version  2.0) 

•  DECnet-20  Version  3.0 

•  DECnet-10  Version  3.0 

In  addition,  the  manual  has  been  reorganized  to  introduce  the  following  new 
Phase  IV  concepts  and  products. 

•  PRO/DECnet  Version  1.0 

•  Ethernet  and  related  hardware 

•  DECnet/SXA  Gateway  (Version   1.1   for  VAXA'MS  and  Version   1.0  for 

RSX-11) 

•  DECnet  Terminal  Server  Version  1.0 

•  DECnet  Router  Server  Version  1.0 

•  DECnet  Router/X.25  Gateway  Version  1.0 

•  Observer  Version  l.l 

The  Purposes  of  the  Introduction  to  DECnet 

Introduction  to  DECnet  describes  the  concepts  and  capabilities  of  DECnet 
networks.  A  DECnet  network  consists  of  two  or  more  Digital  computer  sys- 
tems, enhanced  *.viih  DECnet  software  and  linked  by  means  of  communica- 
tion lines.  DECnet  systems  in  such  a  network  can  communicate  with  each 
other  and  share  resources.  Products  are  also  available  that  enable  DECnet 
systems  to  communicate  with  other  network  entities,  such  as  IBM  SNA  main- 
frames and  packet-switching  data  networks  (PSDNs).  DECnet  networks  can 
be  loca'  area  networks,  wide  area  nt  works,  or  both  combined. 


Ix 


Although  all  implementations  of  DECnet  (for  example.  DECnet-V'AX, 
PRO/DECnet.  DECnet-10.  etc.)  embody  the  same  network  concepts,  all  do 
not  support  the  same  set  of  network  functions.  The  specific  capabilities  of  a 
DECnet  network  depend  on  the  type  of  systems  participating  and  on  the 
network's  application.  The  objectives  of  this  Introduction  are: 

•  To  describe  the  common  network  concepts  behind  all  implementations  of 
DECnet 

•  To  identify  the  major  network  functions  that  DECnet  provides 

Readers  of  the  Introduction 

The  Introduction  is  intended  for  readers  who  want  to  learn  about  the  ctmcepts 
and  capabilities  of  DECnet  systems.  It  a.ssumes  that  the  reader  is  familiar 
with  operating  system  concepts,  but  not  vith  DECnet.  Typical  readers  will 
include  the  personnel  at  the  site  of  a  newly  installed  DECnet  system,  who  can 
read  this  manual  to  learn  about  the  kind  of  work  DECnet  enables  them  to 
perform.  Another  group  of  readers  will  include  system  managers  and  designers 
who  are  thinking  about  using  DECnet  to  expand  their  existing  Digital  com- 
puter systems.  And,  finally,  the  Introduction  is  also  intended  for  system  man- 
agers and  designers  who  do  not  yet  use  Digital  systems,  but  who  are  consider- 
ing the  implementation  of  a  computer  network.  This  manual  will  inform  them 
about  the  network  capabilities  that  DECnet  provides. 

The  Structure  of  the  Introduction 

The  Introduction  consists  of  three  parts,  encompassing  eleven  chapters: 

•  The  first  part.  Chapters  1  to  3,  introduces  the  concepts  and  general  configi 
ration  guidelines  for  DECnet. 

•  The  second  part,  Chapters  4  to  9,  defines  specific  network  functions  and 
explains  the  mechanisms  that  programmers  and  terminal  users  can  employ 
to  implement  those  functions.  Examp'es  of  how  these  capabilities  can  be 
used  in  an  application  environment  are  also  presented  in  this  part  of  the 
book. 

•  The  third  part,  Chapters  10  and  11.  introduces  DECnet  functions  related  to 
the  management  of  the  systems  that  make  up  a  DECnet  network. 

Associated  Documents 

This  Introduction  discusses  many  topics  that  are  explained  in  greater  detail  in 
other  manuals.  The  appendix  section  of  the  Oiercieu  of  Digital  Nvtuorkin^ 
Products  manual  contains  a  complete  list  of  DECnet  manuals  as  well  as 
manuals  on  other  products  pertinent  to  DECnet,  such  as  Ethernet  and  Pack- 
etnet  System  Interfaces  (PSI). 
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Chapter  1 
Defining  DECnet 


This  manual  introduces  you  to  DECnet.  It  tells  you  what  DFTnet  is.  how  and 
where  it  is  used,  and  what  it  offers  you.  The  manual  provides  you  with  a  basic 
orientation  that  can  be  applied  to  all  DECnet  products,  and  it  refers  you  to 
other  manuals  that  provide  more  detailed  information. 


1.1    What  Is  DECnet? 


DECnet  is  the  name  given  to  the  family  of  software  and  hardware  communi- 
cations products  that  enable  Digital  f)perating  systems  to  participate  in  a 
network  environment.  A  network  is  an  aggregate  of  two  or  more  computer 
systems  —  called  nodes  —  connected  to  each  other  by  physical  links  (cable, 
microwave,  or  satellite  links)  for  the  purposes  of  engaging  in  communications 
and  resource  sharing.  Figure  1-1  shows  an  example  of  a  DECnet  network. 

A  DECnet  network  can  be  large,  consisting  of  up  to  1023  nodes,  or  small, 
consisting  of  only  two  nodes.  Any  processor,  intelligent  terminal,  or  other 
computer  system  capable  of  functioning  autonomous'.y  within  a  DECnet  envi- 
ronment can  be  a  DECnet  node.  Nodes  that  are  physically  located  next  to 
each  other  are  called  adjacent  nodes.  Adjacent  nodes  communicate  by  means 
of  logical  communications  paths  —  called  circuits.  Circuits  operate  over  the 
physical  links  between  adjacent  nodes  to  convey  all  communications  and  data 
exchanges  that  occur  in  a  DECnet  network.  Information  is  carried  over  cir- 
cuits from  node  to  node,  enabling  communications  to  reach  any  node  in  the 
network.  Circuits  and  the  way  they  are  used  to  convey  data  are  explained 
more  fully  in  Chapter  2. 

A  very  important  feature  of  a  DECnet  network  is  that  DECnet  nodes  have  a 
peer  relationship  with  each  other.  The  network  does  not  have  to  be  structured 
in  a  hierarchical  manner.  You  can  configure  a  network  in  which  every  node 
can  communicate  with  every  other  node  without  consulting  a  central  control- 
ling node.  In  such  a  decentralized  network,  each  node  can  be  equally  respon- 
sive to  user  requests;  network  users  can  gain  easy  access  to  applications  and 
facilities  that  exist  on  other  nodes:  and  communication  overhead  can  be  re- 
duced. 

Decentralization  also  provides  a  great  deal  of  flexibility  in  the  way  that  net- 
works can  be  configured.  The  type  of  configurations  pc '^sible  in  a  decentral- 
ized network  are  discus.sed  in  Chapter  3. 
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Figure  1-1:    A  DECnet  Network 


1.2    DECnet  Capabilities 


As  described  in  Chapters  4.  5,  6,  7.  and  8.  DECnet  extends  the  following 
capabilities  to  Digital  operating  systems: 

•  Task-to-task  communication.  Two  programs,  on  the  same  or  on  different 
network  systems  can  exchange  data. 

'  H,>mote  file  and  record  access.  DFTnet  provides  both  terminal  and  pro- 
gidm  access  to  files  that  reside  on  remote  nodes.  Remote  file  access  facilities 
allow  you  to  perform  the  following  operations: 

Transfer  files  between  two  nodes 

Manipulate  files  residing  on  a  remote  node  (for  example,  open,  delete,  or 
append  data  to  remote  filesl 

Submit  command  files  to  a  remote  node  for  execution  to  gain  access  to 
that  node's  resources 

•  Terminal-to-terminai  communication.  On  some  DECnet  implementa- 
tions, a  terminal  user  can  use  a  DECnet  utility  to  send  messages  to  other 
terminals  in  the  network. 

^  i^atwork  terminai  communication.  A  local  terminal  can  be  connected  logi- 
cally to  a  remote  node.  Cl'he  remote  node  executes  commands  typed  at  the 
local  terminal.)  In  Phase  III  DPXnet  implementations,  the  remote  node  is  a 
DECnet  node  supporting  the  same  operating  system;  in  Phase  IV  imple- 
mentations, the  remote  node  can  support  a  different  operating  system. 

•  Topology  alternatives.  DECnet  provides  the  following  features,  which  give 
you  considerable  flexibility  when  configuring  a  network: 

Ethernet  configurations 

An  Ethernet  configuration  provides  a  local  area  network  environment 
for  DECnet  users.  Ethernet  is  a  high  performance  environment  and 
supports  a  variety  of  dedicated  communications  servers  as  described  in 
Section  3. 2. 3. 

Adaptive  routing 

Any  node  in  a  DECnet  network  can  communicate  with  any  other  node 
as  long  as  there  is  some  physical  pathway  between  them.  Section  3.2.2 
provides  additional  information  on  adaptive  routing. 

Multipoint  lines 

Several  DECnet  nodes  can  share  a  single  line  in  a  multipoint  configura- 
tion. Section  3.3  provides  additional  information  on  multipoint  lines. 

•  Network  management.  System  managers  can  use  DECnet  commands  and 
procedures  to  generate,  define,  monitor,  and  maintain  DPXnet  nodes. 
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•  Down-line  loading.  System  imajies  and  programs  can  be  down-line  loaded 
to  or  up-line  dumped  from  certain  nodes.  For  example,  an  KSX  IIS  DKC- 
net  node  which  has  crashed  may  up-line  dump  a  copy  ot  its  system  iiiiage  to 
an  RSX   llM  DKCnet  node  tor  interpretation. 

•  Problem  Isolation.  System  manajjers  can  use  DKCnet  commands  and  pro- 
cedures to  exercise  various  network  capaliilities  and  isolate  network  prob- 
lems. Loophack  tests,  trace  facilities,  and  dump  analyzer^  are  some  ol  the 
procedures  available. 

•  Access  to  foreign  vendor  networks.  DKCnet  interacts  with  Digital  gate- 
ways to  enable  users  to  communicate  with  IBM  systems  in  an  SNA  network. 
(iateways  are  also  used  tor  communication  with  nodes  su|)porting  X.2n 
protocol  over  a  packet -switching  data  network  (PSDNi.  Intormation  on  for- 
eign vendor  networks  is  provided  in  Cha[)ter  8. 

•  Data  link  independence.  DKCnet  provides  the  option  ot  communicating 
over  different  data  links.  .Su,/,.')rted  data  links  implement  DDCMP  (Digi 
tal's  data  communications  protocol).  X.2o  (an  international  packet -switch- 
ing protocol)  and  Kthernet  (a  local  area  network  protocol).  The  implemen- 
tation of  any  of  these  data  links  is  tor  the  most  part  transparent  to  the  use*- 
and  the  applications  software.  Section  2.2.2  provides  additional  informal i(tn 
on  data  link  protocol?. 

Chapter  9  contains  examples  of  applications  that  demonstrate  how  these  ca- 
pabilities support  application  interaction. 


1.3    How  Does  DECnet  Work? 


DECnet  nodes  are  able  to  communicate  effectively  by  implementing  a  set  of 
rules  that  govern  how  DKCnet  software  components  relate  to  each  other. 
These  rules  are  collectively  called  the  Digital  Network  Architecture  (DNA). 
As  shown  in  Figure  1-2.  DNA  rules  are  similar  to  those  that  make  up  the 
Reference  Model  tor  Open  Systems  Interconnection  develoj^ed  by  the  liiterna- 
tional  Standards  Organization  (ISO). 

NOTE 

The  framework  of  DNA  is  transparent  for  most  user  activities. 
You  should  be  aware  tha*  DNA  exists  and  that  it  defines  design 
rules  for  DKCnet  software.  However,  you  will  most  likely  have 
no  need  to  be  involved  with  the  details  of  DNA. 

A  brief  summary  of  DNA  is  included  here  for  your  convenience. 
If  you  lequire  further  detail,  refer  to  the  manual  DKCnrt  Digi- 
tal Srtuorh  Architecture  ll'has<'  l\')  (ieneral  liescription 

DNA  defines  two  kinds  of  relationships  between  DKCnet  software  compo- 
nents: 

1.  Interfaces 

2.  Protocols 
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1.3.1    Interfaces 


Interfaces  are  specific  boundaries  that  DNA  defines  between  DECnet  software 
components  residing  within  the  same  node.  These  boundaries  are  structured 
as  a  set  of  vertical  layers  (shown  in  Figure  1-2).  DKCnet  software  is  arranged, 
according  to  function,  as  modules  within  these  layers: 

•  User  layer.  The  I'ser  layer  encompasses  user-written  programs  and  user- 
level  services  that  access  the  network. 

•  Network  Management  layer.  The  Network  Management  layer  software 
defines  the  functions  used  by  operators  and  system  programs  to  plan,  con- 
trol, and  maintain  the  operation  of  DECnet  networks. 

•  Netwck  Application  layer.  The  Network  Application  layer  software  de- 
fines network  functions  used  by  the  I'ser  and  Network  Management  layers. 
The  most  important  DKCnet  functions  currently  operating  in  this  layer  are 
remote  file  access,  file  transfer,  remote  terminal  capability  (including  the 
network  virtual  terminal  function),  access  to  \.2r)  connections  using  a 
Packetnet  System  Interface  (PSI)  or  X.2.VX.29  extension  package,  and  ac- 
cess to  SNA  (iateways.  (Chapters  (>  through  H  discuss  these  capabilities.) 
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•  Session  Control  layer,  l  he  Session  Control  layer  software  defines  a  mech- 
anism that  allows  a  program  in  one  node  to  communicate  with  a  program  in 
another  node,  regardless  of  either  program's  location  in  the  network.  Mod- 
ules in  the  Iser  layer,  the  Network  Management  layer,  and  the  Network 
Application  layer  can  use  the  mechanism  provided  by  the  Knd  Communica- 
tion layer.  This  mechanism  is  called  the  logical  link  and  is  further  explained 
in  Chapter  4. 

^  End  Communication  layer.  The  End  Communication  layer  software  han- 
dles the  syst?m- independent  aspects  of  communications  that  use  the  logical 
link.  These  include  connection  management,  data  flow  control,  end-to-end 
error  control,  and  segmentation/reassembly  of  user  messages.  (See  the  dis- 
cussion on  task-to-task  communication  in  Chapter  5  for  clarification  of 
these  concepts.) 

•  Routing  layer.  The  Routing  layer  software  defines  the  mechanism  for  rout- 
ing user  data  from  the  sending  node  to  the  receiving  node.  Modules  in  this 
layer  also  provide  congestion  control  and  packet  lifetime  control.  (See 
Chapter  2  for  clarification  of  these  concepts.) 

•  Data  Link  layer.  The  Data  Link  layer  software  defines  a  mechanism  for 
error-free  communication  between  adjacent  nodes  whether  they  are  con- 
nected by  an  X.25  link,  an  Ethernet  link,  or  a  DDCMP  link  (point-to-point 
or  multipoint  as  described  in  Section  3.3).  See  Chapter  2  for  a  discussion  of 
Ethernet  and  Chapter  8  for  a  discussion  of  X.25. 

•  Physical  Link  layer.  The  Physical  Link  layer  defines  the  way  that  device 
drivers  and  communications  hardware  (modems,  lines,  etc.)  are  used  to 
move  data  over  a  transmission  line. 

According  to  DNA,  DECnet  software  modules  in  each  layer  have  to  interact 
with  each  other  in  a  specified  way.  A  module  can  use  services  provided  by 
modules  in  a  lower  layer  and  can  provide  services  to  a  higher  layer.  However, 
a  module  cannot  access  services  offered  by  a  module  at  a  higher  layer.  In 
building  block  fashion,  DNA  causes  each  layer  of  software  to  build  on  the 
services  offered  by  the  modules  in  a  lower  layer.  By  adhering  to  these  rules, 
functions  such  as  the  way  communications  are  established  between  two  pro- 
grams occur  in  a  predictable,  regulated  way  on  each  DECnet  node. 

1.3.2   Protocols 

Protocols  are  rules  that  define  the  relationship  between  software  modules 
operating  in  different  nodes.  Simply  put,  protocols  provide  a  common  code  of 
behavior  that  two  computer  systems  in  a  network  can  use  to  understand  the 
role  each  one  is  playing  in  communications  and  information  exchanges. 

Protocols  define  the  form  and  content  of  messages  exchanged  by  software 
modules  that  serve  the  same  network  function  and  reside  in  the  same  DNA 
layer  in  different  nodes.  Figure  1-3  shows  this  relationship. 
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Figure  1-3:    Protocols  and  Interfaces 

D\A  does  not  define  protocols  for  all  functional  layers.  In  some  cases,  such  as 
I'ser  layer  programs  that  communicate  over  the  network,  the  programmer 
must  interpret  the  data  received.  (This  is  similar  to  interpreting  the  contents 
of  a  record  on  disk.)  Furthermore,  multiple  protocols  can  be  defined  for  the 
same  layer,  because  some  layers  support  more  than  one  function.  Also,  the 
protocols  that  DNA  does  define  are  not  exclusive:  users  can  substitute  their 
own  protocols,  if  they  choose,  as  long  as  they  are  implemented  consistently  by 
equivalent  modules  throughout  the  network. 


1.4    DECnet  Phases 


Digital  has  developed  networking  products  based  on  the  DNA  architecture 
since  1975.  This  development  effort  has  occurred  in  a  series  of  phases.  To 
date,  there  have  been  four  DECnet  phases.  The  products  in  each  new  phase 
are  fully  compatible  with  those  produced  in  the  previous  phase.  Sections  1.4.1 
and  1.4.2  describe  capabilities  of  Phase  III  and  Phase  IV  DECnet  nodes. 
(Appendix  B  in  the  Oierview  of  Digital  Networking  I^oducts  contains  a  brief 
history  of  DECnet  and  discussions  of  earlier  DECnet  phases.) 

1.4.1    Phase  III 

DECnet  Phase  III  systems  can  perform  the  following  functions  (see  Section 
1.2): 

•  Task-to-task  communication 

•  Remote  file  access 

•  Terminal-to-terminal  communication 

•  Network  terminal  communication 

•  Network  management 

•  Down-line  loading 

•  Loopback  testing 
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In  addition,  Phase  III  systems  can  perform  message  routing,  multipoint  com- 
munication, and  communications  with  pacl<et -switching  data  networks  using 
X.25  protocols. 

The  following  DECnet  products  provide  Phase  III  capabilities  as  discussed  in 
this  manual. 

•  DECnet -20 

•  DECnet-10 

•  DECnet/E 

•  DECnet-RT 

•  DECnet -IAS 

1.4.2    Phase  IV 

Phase  IV  added  technology  that  established  Digital  as  a  leading  supplier  of 
products  for  multivendor  network  environments.  In  addition  to  being  back- 
ward compatible  with  Phase  III,  Phase  IV  features  include: 

•  Data  link  independence  which  provides  expanded  data  link  options  to  DEC- 
net users.  Data  links  supported  by  DEC-net  are  X.2n.  DDCMP,  and  Ether- 
net links. 

•  Dedicated  communications  server  products  that  off-load  communications 
overhead  from  general  purpose  nodes  (see  Chapter  3). 

•  Increased  network  routing  supp(.rt  allowing  up  to  1023  nodes  to  be  sup- 
ported in  a  network. 

•  Enhanced  network  management  capabilities  (see  Chapters  10  and  11). 

•  (iateway  support  for  communications  with  nodes  u.sing  X.2o  protocol  over  a 
packet-switching  data  network  (see  Chapter  8). 

•  (Jateway  support  for  communications  with  IBM  systems  in  an  SNA  (Sys- 
tem Network  Architecture)  network  (see  Chapter  8). 

The  following  DECnet  products  implement  Phase  IV  capabilities  as  discussed 
in  this  manual: 

•  DECnet-RSX  (llM,  IIM-PLIS.  and  US) 

•  DECnet-VAX 

•  PRO/DECnet 
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1.5    DECnet  Uses 


Some  of  the  advantages  of  a  network  over  a  single  system  or  group  of  uncon- 
nected single  systems  is  that  you  can  use  it  to  increase  the  tlexihility  of  your 
system  and  the  way  you  perform  certain  tasks.  Consider  the  following  ways  in 
which  you  might  use  DKCnei: 

•  Resource  sharing.  In  a  network  environment,  you  do  not  need  to  duplicate 
resources  tor  each  node.  Line  printers,  storage  facilities,  processing  capabili- 
ties and  dedicated  communications  servers  are  among  some  of  the  resources 
that  can  be  shared  by  multiple  nodes. 

•  Remote  file  access.  Having  access  to  files  on  remote  network  nodes  ex- 
pands the  options  you  have  as  to  where  you  create  and  store  information. 
Vou  can  maintain  fewer  copies  ot  a  given  file  and  users  can  always  access 
the  most  current  version. 

•  Distributed  data  bases.  Any  network  node  can  access  information  stored 
on  any  other  network  node.  rhi>.  means  that  users  throughout  the  network 
can  make  use  ol  information  stored  in  common  data  bases. 

•  File  transfer.  Multiple  users  in  a  network  can  exchange  files  rapidly.  This 
capability  >peeds  up  the  information  flow  between  organizations  and  de- 
creases the  amount  ot  paperwork  that  must  be  handled. 

•  Communication  with  foreign  vendor  systems.  I)K('net  interacts  with 
Digital  gateways  and  special  software  products  to  enable  you  to  communi- 
cate with  non-I)K('net  systems.  Vou  can  communicate  with  IBM  SNA  sys- 
tems u>ing  a  DKCnet  SNA  (lateway.  I'sing  a  DPX'net  Router/X.2')  (iate- 
way  and  or  related  software,  you  can  communicate  with  any  node  connected 
to  a  packet -switihing  data  network  that  implements  the  appropriate  X.2') 
protocols.  This  expands  network  access  and  resource  potential  for  communi 
cations  over  a  range  of  different  networks. 

Chapter  9  of  this  manual  discusser  other  applications  of  DECnet  capabilities. 
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Chapter  2 
DECnet  Concepts 


Network  activity  involves  the  tlow  of  information  from  one  node  to  anoth*  r. 
To  understand  how  this  happens  in  a  DKCnet  network,  there  are  some  key 
DFX'net  ("oncepts  you  should  know.  These  concepts  are  described  in  this  chap- 
ter in  the  foilowmg  order: 

•  Nodes 

•  Lines  and  circuits 

•  Routing 


2.1    Nodes 


A  node  is  a  network  entity  an  identifiable  unit  capable  of  processing, 
sending,  and  receiving  network  information.  A  node  consists  of  an  autono- 
mous software  entity  such  as  an  operating  system,  with  processors  and  other 
associated  hardware  implementing  DECnet  products  to  perform  network  op- 
erati(»ns.  Flvery  node  in  a  DKCnet  network  has  a  unique  numeric  address. 
This  address  designates  the  location  of  a  node  in  the  network  just  as  a  street 
address  designates  the  location  of  a  building  in  a  town.  When  a  packet  of  data 
is  sent  from  one  node  to  another,  it  is  enveloped  by  control  information,  which 
includes  the  address  of  the  .sending  node  (called  the  source  address)  and  the 
address  of  the  receiving  node  (called  the  destination  ac.dress).  This  informa- 
tion tells  nodes  that  intercept  the  packet  en  route  lo  its  c'estination  where  the 
packet  is  going.  Node  addresses  ensure  that  a  data  packet  can  always  be 
identified  in  terms  of  who  is  sending  it  and  who  is  receiving  it.  no  matter 
where  in  the  network  it  travels.  (See  Section  '2. A  for  a  discussion  of  the  routing 
mechanism  that  determines  data  packet  paths.) 
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For  most  users,  however,  addresses  are  difficult  to  remember,  particularly 
when  you  are  dealing  with  a  large  number  of  nodes.  Therefore,  nodes  can  be 
assigned  node  names,  which  are  easier  to  remember.  The  system  manager  for 
each  node  specifies  names  for  all  the  nodes  with  which  that  node  expects  to 
communicate.  These  names  are  defined  in  the  local  data  base  and  are  mean- 
ingful only  to  the  local  software.  Each  system  manager  can  define  a  different 
node  name  for  the  same  remote  node.  (DECnet  software  in  each  node  keeps  a 
list  containing  the  node  address  associated  with  each  node  name.  The  node 
address  defined  for  each  node  must  be  consistent  throughout  the  network.) 
This  allows  users  to  refer  to  nodes  by  name  and  the  software  to  find  the 
correct  address  of  a  node  in  order  to  route  data  properly. 

The  node  name  and  address  by  which  a  node  is  to  be  known  in  the  network  are 
usually  assigned  by  the  system  manager  when  a  node  is  initially  generated  or 
configured  into  the  network.  For  small  networks,  these  assignments  can  be 
hand-typ^d  into  each  system:  for  large  networks,  it  is  recommended  that  an 
up-to-dat  master  list  of  node  addresses  and  names  be  maintained  on  a  par- 
ticular node.  That  way.  other  nodes  in  the  network  can  simply  ^^^  py  the 
information  from  the  master  file.  (Existing  nodes  in  the  network  exchange 
their  node  names  and  addresses  with  each  newly  configured  node.) 

Refer  to  the  system  manager's  guide  for  your  svstem  for  more  information  on 
specifying  node  names  and  addresses.  Other  node  characteristics,  such  as 
routing  capabilities  and  dedicated  functions,  are  discus.sed  in  Chapter  ',],  as 
they  apply  to  network  configurations. 


2.2    Lines  and  Circuits 


As  noted  in  Chapter  1.  a  line  is  a  physical  data  path  from  a  DECnet  node  to 
another  DECnet  node,  or  from  a  gateway  to  an  IBM  SNA  network  or  packet - 
switching  data  network  (FSDX).  A  line  is  connected  to  a  node  by  a  hardware 
controller  that  drives  the  line.  Lines  that  use  the  public  telephone  network  are 
also  often  connected  to  a  modem.  Lines  can  be  either  dedicated  (hard-wired) 
or  dial-up.  Lines  can  be  attached  to  a  local  area  network  cable  or  configured  in 
point-to-point  or  multipoint  configurations  (as  described  in  Chapter  3). 

Whereas  lines  form  the  physical  confM^ctions  between  adjacent  nodes,  there  is 
a  higher  level  concept  of  internodai  connections  called  circuits.  Circuits  are 
logical  connections  that  carry  information  between  two  nodes  and  operate 
over  the  physical  medium  of  lines.  Each  point-to-point  line  has  one  circuit 
associated  with  it  and  each  tributary  on  a  multipoint  line  has  (me  (as  shown  in 
Figure  2  1). 
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Ethernet  uses  one  physical  line  with  multiple  circuits.  Each  circuit  corre- 
sponds to  a  particular  Ethernet  protocol  type.  An  Ethernet  protocol  type 
identifies  the  type  of  operation  performed  over  each  circuit.  For  example,  the 
following  protocol  types  are  shown  in  Figure  2-1: 


• 


DNA  routing  protocol.  Enables  the  DECnet  routing  mechanism  (see  Sec- 
tion 2.3)  and  is  required  for  all  DECnet  communications. 


•  DNA  remote  console  protocol.  Provides  simple  internodal  terminal  com- 
munications used  for  diagnostic  and  maintenance  procedures. 

•  DNA  dump/load  protocol.  Enables  you  to  load  nodes  that  do  not  have 
mass  storage  (for  example,  communication  servers). 

•  Loopback  protocol.  Enables  you  to  perform  loop  tests  and  is  required  for 
any  type  of  testing  procedures  (see  Chapter  11). 

There  are  other  protocol  types  not  shown  in  Figure  2-1.  Refer  to  the  bibliogra- 
phy in  the  Ovenivu  of  Digital  Networking  Products  for  a  list  of  Ethernet 
documentation  that  further  explains  protocol  types. 

It  is  important  to  note  that  all  communication  activity  in  the  network  is 
considered  in  terms  of  circuits.  A  succession  of  circuits  between  a  number  of 
intervening  nodes  can  be  established  by  the  routing  mechanism  described  in 
Section  2.3  to  get  data  from  one  node  to  another.  These  circuit  pathways 
enable  nodes  to  send  data  to  other  nodes  that  are  not  physically  adjacent  to 
them. 

2.2.1    Transmission  IVIodes 

Information  is  transmitted  over  DECnet  lines  in  half  duplex  or  full  duplex 
mode. 

Half  duplex 

The  line  can  transmit  data  in  either  direction,  but  only  in  one  direction  at  any 
given  time.  In  other  words,  data  cannot  be  sent  and  received  over  the  line 
simultaneously. 

Full  duplex 

The  line  can  transmit  data  in  both  directions  simultaneously.  Full  duplex 
allows  a  node  to  send  and  receive  data  at  the  same  time. 

Half  duplex  and  full  duplex  relate  to  the  physical  line  only.  Information  flow 
at  the  higher  level  of  the  circuit  always  appears  to  be  full  duplex.  The  user 
sends  data  and  it  is  handled  by  various  layers  of  DECnet  software  until  it 
reaches  the  routing  mechanism  (see  Section  2.3).  The  routing  mechanism 
determines  the  circuit  over  which  the  data  will  be  transmitted  to  an  adjacent 
node  according  to  precomputed  information.  The  data  is  then  passed  on  to 
software  that  handles  various  data  link  protocols  (such  as  those  described  in 
the  following  section). 
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As  far  as  the  user  and  the  routing  mechanism  are  concerned,  the  data  has 
been  transmitted  over  the  specified  circuit.  However,  if  the  data  cannot  be 
transmitted  over  the  designated  physical  line  because  it  is  a  half  duplex  line 
already  carrying  data,  or  in  the  case  of  an  Flthernet  transmission,  because  the 
channel  is  not  free,  DECnet  software  will  buffer  the  data  until  transmission 
can  be  accomplished.  The  user  is  not  aware  of  when  the  data  is  actually 
buffered  or  when  it  is  sent  out  direct Iv  on  a  free  line. 


2.2.2    Data  Link  Protocols 

DKCnet  uses  two  basic  protocols:  Digital  Data  Communications  Message  Pro- 
tocol (DDCMP).  which  is  a  byte-oriented  protocol,  and  Ethernet  protocol 
with  physical  channel  encoding. 

A  byte-oriented  protocol  provides  a  count  of  the  number  of  bytes  that  will  be 
sent  in  the  data  portion  of  each  message.  The  receiver  of  the  message  can 
compare  the  number  of  bytes  actually  received  to  the  number  sent  by  the 
protocol  as  a  means  of  error  detection.  Circuits  established  between  two  adja- 
cent DECnet  nodes  use  DDCMF. 

Physical  channel  encoding  uses  '.he  carrier  signal  to  indicate  the  beginning 
and  end  of  a  message.  When  a  signal  is  detected  by  the  intended  receiver  of  a 
message,  the  message  has  begun  transmission.  When  the  signal  ends  and 
clock  transition  is  no  longer  detected,  the  message  has  ended.  Ethernet  cir- 
cuits use  the  Ethernet  protocol  with  Manchester  physical  channel  encoding. 
Refer  to  the  Hthtrrn't  lyociucts  and  Senices  i^italog  for  detailed  information. 

NOTE 

See  Chapter  8  for  a  discussion  of  X.2n  and  DFXnet/SNA  data 
links  and  circuits. 


2.3    Routing 


Routing  is  the  network  function  that  determines  the  path  or  "route"  along 
which  a  packet  of  data  travels  to  its  destinaticm.  A  path  consists  of  the  se- 
quence of  circuits  and  nodes  located  between  the  source  node  and  the  destina- 
tion node.  In  many  cases,  there  are  multiple  paths  between  network  nodes  (as 
shown  in  Figure  2-2). 

How  do  you  know  over  which  path  to  send  data'.'  What  do  you  do  if  a  line  on 
the  path  goes  down''  Fortunately,  DECnet  software  implements  a  routing 
mechanism  on  each  node  that  handles  that  worry  for  you. 

Vou  simply  address  and  transmit  data  according  to  the  type  of  function  you 
are  using  (user  program,  terminal  utility,  and  so  on).  The  DECnet  routing 
mechanism  deciphers  the  destination  address  of  the  packet  and  forwards  it 
along  to  the  destination  node  according  to  a  precomputed  path  that  may 
include  intervening  nodes.  (The  path  is  computed  by  the  routing  function 
according  to  information  on  path, cost  and  distance  that  is  kept  in  a  routing 
data  base  in  each  DECnet  node.  This  information  is  updated  dynamically  if 
conditions  in  the  network  change.  For  example,  if  a  line  goes  down,  nodes 
affected  by  that  line  would  recompute  their  routing  information  to  direct  data 
traffic  over  an  alternate  path.) 
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Figure  2-2:    Routing  Paths 

When  a  message  is  sent  to  an  Ethernet  node  from  a  node  not  connected  to  the 
Ethernet,  it  must  be  received  by  a  routing  node.  The  routing  node  submits  the 
message  to  the  Ethernet  channel.  The  message  travels  along  the  Ethernet 
channel  until  it  reaches  the  destination  node.  (The  destination  node  can  rec- 
ognize and  retrieve  messages  addressed  to  it.) 

If  a  message  originates  on  an  Ethernet  and  is  addres.sed  to  another  node  on  the 
same  Ethernet,  a  routing  node  is  not  necessarv.  The  sender  transmits  the 
message  directly  to  the  destination  as  if  they  had  a  point-to-point  connection. 

NOTE 

If  you  are  implementing  X:>r>  protocol  through  a  gateway  node 
rather  than  through  data  link  mapping  as  discussed  in  Chapter 
8.  DECnet  routing  is  not  used  over  the  FSI)\.  The  PSDN 
handles  all  routing  functions  that  occur  within  its  boundaries. 
(See  Chapter  8  for  an  explanation  of  X.2o  implementations.) 

2.3.1    Routing  Terms 

The  total  distance  between  a  source  node  and  its  destination  is  called  the  path 
length.  The  path  length  is  measured  in  hops.  A  hop  is  equal  to  a  circuit 
between  two  nodes.  A  path  never  exceeds  a  maximum  number  of  hops  which 
IS  a  value  set  by  a  system  manager  or  determined  bv  the  DECnet  implementa- 
tion. 
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The  cost  ot  each  path  between  a  source  node  and  a  destination  node  is  deter- 
mined by  the  sum  ol  positive  integer  vahies  assigned  to  the  circuits  that 
compose  the  path.  Kach  integer  value  is  called  a  circuit  cost. 

When  generating  a  network  data  base,  a  system  manager  or  operator  assigns  a 
cost  to  each  circuit  defined  Ibr  that  node.  When  the  node  is  up  and  running, 
an  operator  can  dynamically  change  individual  costs  to  higher  or  lower  values. 
Altering  circuit  costs  can  change  packet -routing  paths.  Figure  2  '^  shows  the 
correlation  between  path  length,  hops,  and  |)ath  cost. 
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Figure  2-3:    Routing  Terms 
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2.3.2    Other  Routing  Features 

In  addition  to  delerniiniii^  |)ath  length  and  p.uh  (ost.  the  roiitiii^  iiu'chaiii^ni 
also  does  the  following  thinjis; 

•  Limits  the  number  ot  packets  (jueuin^  up  jor  tran>mi>si<iii  nn  mdividual 
circuits. 

•  Regulates  the  ratio  ot  packets  to  he  forwarded  ihroi.'gh  a  node  with  thuse 
that  are  generated  on  the  node,  to  achieve  a  reasonal)le  halance  ot  trallic 
trom  both  sources. 

•  Tracks  the  number  ot  nodes  a  route-t  hrough  packet  has  \  isiled  and  dix  ards 
packets  that  have  exceeded  a  predefined  limit.  Thi^  ensure*-  that  packets 
can  never  loop  enidessly  through  the  network. 

Although  the  routing  mechamsm  has  been  designed  to  operate  with«»ut  need 
of  direct  user  intervention,  system  :nanager>  and  operators  can  exercise  some 
control  over  routing  performance  i)y  mampulatmg  certain  configuration 
parameters  such  as  maximum  path  lengths  and  circuit  costs.  A  svstem  mana- 
ger can  define  imtial  values  for  these  |)arameters  when  building  a  l)K('net 
system  for  a  node.  These  values  can  also  be  modified  after  a  DKCnet  svstem 
has  been  installed  to  improve  performance  or  to  refleit  changes  in  the  network 
configuration. 

Routing  parameters  should  be  deteriTiined  otilv  after  careful  consideration  of 
their  effects  on  the  local  node  and  on  the  network  as  a  whole.  See  the  DKCnel 
system  managers  guide  for  your  particular  system  for  information  on  which 
routing  parameters  vou  can  spec  ify  and  how  to  '>pecify  them. 
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Chapter  3 

DECnet  Configurations 


Understanding  the  DECnet  concepts  presented  in  Chapter  2  will  help  you  to 
understand  how  nodes  and  lines  can  be  arranged  in  various  configurations. 

As  discussed  in  Chapter  2,  the  routing  mechanism  enables  nodes  that  are  not 
directly  connected  to  each  other  by  physical  lines  to  communicate.  This  al- 
lows great  flexibility  in  the  way  that  nodes  and  lines  can  be  combined  in 
networks.  The  major  factors  that  determine  how  you  can  join  these  compo- 
nents are: 

•  The  requirements  of  the  tasks  to  be  performed 

•  The  capabilities  of  the  network  components 

Scenarios  related  to  the  first  factor  are  discussed  in  the  Overview  of  Digital 
Networking  Products.  These  scenarios  illustrate  how  network  components  can 
be  mixed  and  combined  in  configurations  that  suit  individual  needs.  You  may 
want  to  refer  to  these  examples  when  defining  the  requirements  of  your  spe- 
cific tasks. 

The  capabilities  of  the  components  will  dictate  the  bounds  within  which  you 
can  create  network  configurations  to  meet  your  needs.  These  capabilities  are 
discussed  in  this  chapter  as  follows: 

•  The  environment.  There  are  two  basic  environments  in  which  you  can 
create  DECnet  configurations:  wide  area  networks  and  local  area  networks. 
You  can  combine  these  environments  (see  Figure  3.9).  Each  environment 
supports  different  types  of  configurations. 

•  Node  characteristics.  Certain  characteristics  of  a  node,  such  as  its  ability 
to  receive  and  forward  messages  intended  for  other  nodes  and  the  type  of 
network  services  it  can  perform,  greatly  affect  how  you  position  it  in  a 
network  configuration.  Whether  the  node  implements  DNA  Phase  III  or 
Phase  IV  software  is  also  an  important  considerati(m. 
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•  Line  and  circuit  characteristics.  Lines  and  their  associated  circuits  can  he 
arranged  in  configurations  such  as  bus  structures,  point-to-point  arrange- 
ments, or  multipoint  arrangements. 


NOTE 

This  chapter  on  configurations  is  not  intended  to  describe  con- 
figuration programs  for  specific  DECnet  systems  or  to  give  you 
definite  specifications  for  configuring  your  network.  Rather,  it 
is  a  general  discussion  on  the  types  of  configurations  that  are 
possible  using  DFXnet.  For  specific  information  on  how  to  con- 
figure a  system  into  the  network,  refer  to  the  system  manage-'s 
guide  for  your  particular  DECnet  system. 


3.1    DECnet  Environments 


There  are  two  basic  environments  for  DECnet  configurations:  wide  area  net- 
works and  local  area  networks  (LANs).  Figure  .'i-1  shows  an  example  of  a  wide 
area  network,  and  Figure  3-2  shows  an  example  of  a  local  area  network. 

Each  type  of  network  can  be  configured  with  a  variety  of  nodes  and  links,  as 
defined  in  Sections  3.2  and  3.3.  However,  only  Phase  W  DP'Cnet  nodes  can  be 
directly  connected  to  a  local  area  network  cable. 

The  distinctions  between  these  networks  are  most  important  in  terms  of  con- 
figurations. The  end  user  does  not  see  any  apparent  difference  between  com- 
munications with  nodes  on  a  wide  area  network  and  those  on  a  local  area 
network  except  that  performance  improves  over  the  local  area  network. 


3.1.1    Wide  Area  Networks 

A  wide  area  network  is  composed  of  nodes  connected  by  individual  communi- 
cations links  configured  in  various  patterns  as  shown  in  Figure  3-1. 

These  networks  are  used  to  transfer  data  over  distances  ranging  from  a  few 
feet  to  thousands  of  miles.  This  disparity  in  distance  occurs  because  (a)  wide 
area  networks  are  always  used  for  long  distance  communications,  (b)  there  are 
some  short -distance  connections,  such  as  a  point-to-point  connection  between 
two  nodes  or  a  connection  between  time-critical  nodes,  where  it  is  impractical 
to  set  up  a  local  area  network.  Such  short  distance  communications  are  better 
handled  using  high  speed  coaxial  cable  and  other  traditional  communications 
hardware. 


«* 


• 


S-2       Introduction  to  DECnet 


X  29 

NODE  H 

TEPMINAL 

DE(."«!   VAX   PSi 

9 

OTHER  X  25 

USER  OR  Nf  TAOHK 
^  (NON  DiGi'ALi 

TO 

OTHER 
DECnet 
NODES 


NODE  G 

DEC"#t  SNA 
GATEWA, 


OTHER  DECnet  NODES 

ivARiOuS  OPERATING  SySTEMSi 


Figure  3-1 :    Wide  Area  Networl(  Configurations 


Messages  can  be  transported  in  a  wide  area  network  over  leased  or  switched 
lines.  Typically,  wide  area  networks  use  common  carriers,  such  as  the  tele- 
phone network,  to  transport  messages  over  most  or  part  of  these  distances. 
Because  wide  area  networks  use  the  telephone  system  tor  most  communica- 
tions, modems  or  modem  equivalents  are  generally  needed  on  each  end  of  a 
communications  link  to  convert  digital  data  to  analog  form  and  to  permit 
transmission  over  long  distances. 

Different  transmission  speeds  can  be  specified  for  different  communications 
lines  in  a  wide  area  network.  Transmission  speeds  depend  on  the  supported 
hardware  devices  and  the  type  of  lines  used.  This  allows  some  leeway  in 
distributing  work  loads  and  adjusting  performance  levels  for  various  network 
components. 
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You  can  combine  nodes  in  wide  area  configurations  according  to  the  guide- 
lines discussed  in  Section  l].2.  Any  restrictions  to  wide  area  node  configura- 
tions, such  as  nodes  that  can  be  connected  only  to  a  local  area  network,  are 
identified  in  that  section. 

Examples  of  wide  area  networks  include: 

•  Private  packet-switched  networks,  such  as  the  data  networks  developed  by 
many  companies 

•  Public  packet -switched  networks,  such  as  public  data  networks  using  X.25 
protocol  (for  example.  Telenet  and  Transpac) 

•  [.eased  line  networks 

3.1.2    Local  Area  Networks 

Local  area  networks  are  privately  owned  networks  that  offer  reliable  high 
speed  communication  channels.  These  networks  are  optimized  for  connecting 
information-processing  equipment  in  a  limited  geographic  area  —  namely,  an 
office,  a  buili  ig,  or  a  complex  of  buildings,  such  as  a  campus.  These  net- 
works can  be  designed  with  a  variety  of  technologies  and  arranged  in  different 
configurations.  Consequently,  they  vary  with  respect  to  their  transmission 
speeds,  the  distances  they  can  span,  and  the  capabilities  and  services  they 
offer. 

Digital  Equipment  Corporation.  Intel  Corporation,  and  Xerox  Corporatiim 
have  collaborated  to  produce  the  Ethernet  specification,  which  defines  a  local 
area  network  having  specific  characteristics  (see  Figure  .'i-2).  Digital's  Ether- 
net protocol  is  implemented  in  the  DNA  architecture  (see  the  DECnet  Digital 
\rtunrk  Architecture  Phase  IV  (ieneral  Description  and  the  Institute  of  Elec- 
trical and  Electnmics  Engineers  (IEEE)  802.M  draft  standard  for  details). 
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Figure  3-2:    A  Local  Area  Network  —  Ethernet 
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Ethernet  is  characterized  by  one  or  several  segments  of  coaxial  cable  joined 
together,  each  segment  ranging  from  20.4  to  ri()()  meters  long.  The  P^thernet 
cable  is  terminated  at  both  ends  (as  shown  in  Figure  '.l-'A). 


D 


a 


Figure  3-3:    Ethernet  Cable 

A  Phase  IV  Ethernet  network  supports  up  to  102.'^  nodes.  Ethernet  supports  a 
bus  topology,  with  each  node  attached  to  the  cable  by  a  single  line.  The 
channel  bandwidth  of  an  Ethernet  is  lOMB  with  a  CW  throughput  for  each 
controller  set  at  a  maximum  of  l..'iMB.  This  is  considerably  faster  than  con- 
ventional contlgurations. 

Nodes  that  support  a  I'NIBrS  structure,  such  as  PDF  11  and  VAX  nodes, 
connect  to  Ethernet  by  means  of  a  network  adapter  called  the  DEl'NA;  nodes 
wi\h  a  Q-Bl'S  structure,  such  as  micro- 11  systems,  connect  using  a  network 
adapter  called  the  DEQNA.  The  DEINA  and  the  DFIQNA  each  incorporate 
hardware  module  boards,  a  distribution  panel,  and  cabling  that  is  installed  as 
a  communications  device  in  a  DECnet  node.  These  adapters  connect  to  the 
H4(HK)  transceiver  physically  and  electrically  by  a  transceiver  cable  (as  shown 
in  P'igure  3-4). 
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Figure  3-4:    Ethernet  Hardware 
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A  maximum  of  1()0  transceivers  tan  be  used  on  a  single  r)(K)  meter  segment  of 
Ethernet  cable.  A  communications  controller  called  the  DKLNI  allows  you  to 
connect  up  to  eight  nodes  or  devices  to  each  H4(MH)  transceiver.  (You  can  also 
use  the  DELNI  apart  from  the  Ethernet.  In  this  case,  the  DELNI  and  con- 
nected devices  form  a  local  area  network  of  their  own.  When  not  connected  to 
an  Ethernet.  DFlLNIs  can  be  nes.?d  1  deep  to  provide  <i4  connections.)  Figure 
3-5  shows  FRO/DECnet  nodes  on  a  DELNi  attached  to  an  Ethernet  cable. 
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As  mentioned  previously,  segments  of  cable  can  be  connected  to  extend  Eth- 
ernet beyond  the  olH)  meter  limit  of  a  single  segment.  Two  cable  segments  are 
joined  using  a  device  called  a  repeater  (see  Figurt  :i  H). 

A  repeater  enables  the  two  cable  segments  to  function  as  if  they  were  one 
cable.  It  amplifies  transmission  signals  and  |)asses  data  packets  between  two 
coaxial  cable  segments  without  filtering  signals.  Digital  local  area  networks 
can  use  two  types  of  repeaters; 

•  Local  repeater,  ('onnects  two  coaxial  cable  segments  within  a  limited  geo- 
graphic distance,  for  example,  within  a  building.  There  can  be  a  maximum 
of  HH)  meters  between  the  two  cable  segments  and  each  cable  segment  can 
be  a  maximum  of  ')()()  meters  long. 

•  Remote  repeater.  Connects  two  coaxial  cable  segments  spanning  a  dis- 
tance greater  than  that  covered  by  a  local  repeater,  for  example,  between 
two  buildings.  The  remote  repeater  consists  of  two  local  repeaters  connected 
by  a  fiber  optic  link  up  to  KKH)  meters  (M282  feet)  long. 

Both  local  and  remote  repeaters  connect  to  an  H4(K)()  transceiver  on  the  coax- 
ial cable  using  transceiver  cables  (see  Figure  '.\  H).  No  more  than  two  repeaters 
can  be  placed  between  any  two  nodes  on  the  Ethernet. 
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Other  charaiteristics  of  Ktheriiet  coniigurations  are: 

•  'I'raiisceiver  cables  fonnectinji  nodes  to  the  Kthernet  cannot  exceed  ")()  me- 
ters. 

•  Cable  sejjments  must  be  terminalcH  i"  .*)()  ohms, 

•  The  i.iaximiim  distance  between  any  two  nodes  is  2H()()  meters.  (This  in- 
cludes the  lenjjth  ol  the  Kthernet  cable,  the  transceiver  cable,  a  local 
repeater,  and  a  remote  re|)eater.) 

All  DKCnet  nodes  directly  connected  to  an  Kthernet  cable  must  be  Phase  I\' 
DKC'net  n(tdes.  However.  I^hase  III  n(»des  or  Phase  I\'  nodes  not  on  the  Kther- 
net can  ^ain  access  to  Kthernet  resources  through  a  DKCnet  Router  Server,  a 
DKCnet  Kouter/X.25  (iateway,  or  a  lull-tunclion  Kthernet  node. 
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All  server  nodes  described  in  Section  3.2.3  are  supported  on  the  Ethernet. 
(There  is  a  DECnet/SNA  Gateway  implementation  that  supports  DEC- 
net/SNA  communications  in  a  wide  area  network  configuration  as  well.)  Each 
server  node  on  the  Ethernet  is  down-line  loaded  by  a  designated  host  node  on 
the  same  Ethernet  cable.  A  host  node  is  a  full  capability  DECnet  node  whose 
services  are  required  in  the  start-up  procedures  or  operations  of  another  node, 
as  in  the  case  of  down-line  loading.  Documentation  for  each  server  node  in- 
cludes installation  information  describing  the  requirements  of  a  host  node. 

One  type  of  DECnet  system,  called  PKO/DECnet.  can  participate  in  network 
activities  only  as  an  Ethernet  node.  (PRO/DECnet  software  enables  a  Profes- 
sional 300  series  personal  computer  to  participate  as  a  node  in  a  DECnet 
network.  PRO/DECnet  is  distinguished  by  a  menu-driven  user  interface.  Re- 
fer to  the  PRO/DECnet  manual  set  for  more  specific  information.)  Once  at- 
tached to  an  Ethernet,  however.  PRO/DECnet  can  access  wide  area  resources 
as  can  any  other  DECnet  node  —  using  routers  or  other  Phase  IV  DECnet 
nodes  that  span  the  two  networks  (see  Figure  3-9). 

Nodes  connected  to  an  Ethernet  cable  can  connect  with  wide  area  networks, 
other  local  area  networks,  packet -switched  data  networks  that  implement 
X.25  protocol,  and  IBM  systems  using  SNA  protocol.  In  fact,  as  shown  in 
Figure  3-9,  X.25  and  SNA  Gateways  can  connect  directly  to  the  Ethernet. 

For  more  information  on  Ethernet,  refer  to  the  following  Digital  manuals: 

•  Introduction  to  Local  Area  Networks 

•  Ethernet  f^roducts  and  Services  Catalog 


3.2    Node  Characteristics 


The  following  node  characteristics  are  important  considerations  in  network 
configurations: 

•  Phase  III  or  Phase  IV  DNA  implementation 

•  Routing  capabilities 

•  Dedicated  or  general  purpose  function 

These  characteristics  are  discussed  in  the  three  subsections  that  follow. 

3.2.1    Phase  III  and  Phase  IV  Nodes 

As  mentioned  in  Chapter  1  of  this  manual.  DECnet  products  have  been  devel- 
oped in  a  series  of  phases.  Not.  all  Digital  operating  systems  implement  the 
same  phase  of  DECnet,  nor  do  they  all  implement  the  full  capabilities  of  each 
phase.  Chapter  1  discusses  the  DECnet  phases  and  capabilities  currently 
supported  by  each  Di.t;ital  operating  system. 
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In  planning  a  network  configuration,  the  phase  of  DPX^net  that  is  installed  on 
a  node  is  important,  since  Phase  IV  DECnet  extends  the  networking  capabili- 
ties of  a  node  beyond  what  is  offered  in  Phase  III.  Phase  IV  capabilities  that 
affect  configurations  are  as  follows: 

•  Only  Phase  IV  nodes  can  directly  connect  to  an  Ethernet  cable.  Phase  III 
nodes  can  communicate  with  Ethernet  nodes  through  a  router  server  or  a 
Phase  IV  node. 

•  The  Phase  IV  routing  mechanism  supports  network  communications  involv- 
ing up  to  1023  nodes,  while  Phase  III  supports  communications  for  up  to  255 
nodes. 

•  Communications  servers,  described  in  Section  3.2.3,  all  implement  Phase 
IV  software.  Servers  are  important  to  configuration  plans  because  they  off- 
load functions,  such  as  routing  decisions  (Chapter  2)  and  virtual  terminal 
capabilities  (Chapter  7),  normally  performed  by  a  general  function  node.  In 
an  Ethernet  environment,  for  example,  you  could  install  a  number  of  nodes 
without  routing  software  (end  nodes)  if  you  have  a  DECnet  Kouter  Server. 
(Nodes  without  routing  software  are  less  expensive  than  nodes  with  it.)  The 
router  would  provide  routing  functions  for  these  end  nodes. 

Throughout  this  manual.  Phase  III  and  Phase  IV  distinctions  will  be  identi- 
fied and  discussed  as  they  affect  various  aspects  c)f  network  operations. 
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3.2.2    Routing  Capabilities 

There  are  two  labels  applied  to  DECnet  nodes  to  characterize  their  routing 
capabilities: 

•  B^nd  node 

•  Full-function  node 

End  node 

End  nodes  do  not  have  route-through  capability.  This  means  that  they  cannot 
receive  and  forward  messages  intended  for  other  nodes.  An  end  node  can  send 
packets  to  an  adjacent  node.  If  an  end  node  has  multiple  circuits  to  one  or  to 
several  adjacent  nodes,  only  one  of  those  circuits  can  be  active  at  a  time. 

If  a  node  adjacent  to  an  end  node  is  a  full-function  node,  its  route-through 
facilities  can  be  used  by  the  end  node  to  establish  connections  with  other 
nodes  in  the  network.  Nodes  A,  D,  and  H  in  Figure  3-7  are  end  nodes. 
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Full-function  node 

Full-function  nodes  can  have  multiple  circuits  actively  communicating  with 
one  or  several  nodes  at  the  same  time.  Full-function  nodes  also  maintain  an 
up-to-date  map  of  the  network  in  their  data  base.  The  map  provides  informa- 
tion, such  as  the  node  address  of  each  accessible  node  in  the  network.  This 
information  is  used  by  the  routing  mechanism  to  determine  the  most  cost- 
effective  paths  for  sending  data  to  a  destination  node.  Data  destined  for  a 
node  that  is  not  adjacent  to  the  sending  node  can  be  routed  though  one  or 
more  full-function  nodes.  Nodes  B,  C,  E.  F,  and  G  in  Figure  3-7  are  full- 
function  nodes. 
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Flgure  3-7:    Node  Routing  Capabilities 

Chapter  2  describes  the  routing  mechanism  and  how  it  determines  the 
munication  paths  through  a  network. 

3.2.3   General  Purpose  and  Dedicated  Nodes 

Another  factor  that  affects  the  way  networks  are  configured  is  whether  or  not 
particular  nodes  in  the  network  are  general  function  or  dedicated  purpose 
nodes.  Dedicated  nodes  have  specific  functions  that  can  service  the  needs  of 
many  other  nodes.  For  example,  as  shown  in  Figure  3-8,  some  dedicated 
DECnet  nodes  provide  routing  services  to  a  group  of  nodes  on  an  Ethernet 
cable,  others  act  as  gateways  to  other  networks.  Most  of  the  dedicated  nodes 
discussed  in  this  manual  must  be  configured  on  an  Ethernet  cable.  The  one 
exception  is  an  implementation  of  the  DECnet/SNA  Gateway,  which  can  also 
be  configured  in  a  wide  area  network.  General  purpose  nodes  can  be  config- 
ured in  a  wide  area  or  local  area  network  environment. 
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Figure  3-8:    General  Purpose  and  Dedicated  Nodes 

DECnet  nodes  performing  dedicated  communications  functions  are  called 
communications  servers.  The  communications  servers  discussed  here  imple- 
ment Phase  I\'  DECnet  software.  (Because  these  servers  are  dedicated  to  a 
specific  function,  they  cannot  be  accessed  as  regular  Phase  IV  nodes  for  gen- 
eral user  functions.) 

DECnet  communications  servers  must  be  down-line  loaded  by  a  DECnet  host 
node  (Phase  I\')  on  the  Ethernet  cable.  (The  exception  to  this  is  the  DEC- 
net/SNA (iateway.  A  DECnet/SNA  Gateway  can  be  attached  to  an  Ethernet 
and  down-line  loaded,  or  it  can  be  located  in  a  wide  area  network  and  loaded 
directly  from  floppy  disk.)  DECnet  communications  servers  perform  the  fol- 
lowing functions: 

Router  Server.  A  Phase  IV  DECnet  node  that  performs  routing  functions 
only.  The  router  server  connects  with  an  Ethernet  cable  on  one  side  and  with 
other  communications  servers.  Phase  III  nodes,  or  Phase  IV  nodes  on  the  other 
side. 

Routers  provide  a  way  through  which  nodes  on  and  off  the  Ethernet  cable  can 
communicate  with  each  other.  Nodes  in  wide  area  networks  or  other  local  area 
networks  can  also  communicate  with  Ethernet  nodes  by  sending  messages 
through  a  full-function  Phase  IV  DECnet  node  connected  to  the  Ethernet 
cable.  (In  each  case,  access  is  provided  through  the  routing  mechanism  as 
described  in  Section  2.M.)  You  can  also  use  virtual  terminal  facilities  as  de- 
scribed in  Chapter  7  to  form  connections  between  F^thernet  and  non-Ethernet 
nodes. 


DECnet  Configurations      3-11 


Terminal  Server.  A  Phase  IV  DECnet  node  that  enables  a  number  of  termi- 
nals to  communicate  with  multiple  host  nodes.  Terminal  servers  are  con- 
nected to  an  Ethernet  cable.  Terminals  using  the  terminal  server  can  commu- 
nicate with  Phase  IV  DECnet  hosts  on  or  off  an  Ethernet  cable. 

Router/X.25  Gateway.  A  Phase  IV  DECnet  node  that  combines  all  of  the 
routing  capabilities  discussed  for  the  router  server  with  X.25  Gateway  capa- 
bilities. The  X.25  Gateway  capabilities  allow  this  server  to  connect  a  DECnet 
node  running  specific  X. 25-compatible  software  packages  with  other  nodes  on 
a  packet -switched  data  network.  Router/X.25  Gateways  are  connected  to  the 
Ethernet  cable  tm  one  side  and  to  a  packet-switched  data  network  on  the 
other  side.  However,  wide  area  network  nodes  can  also  use  the  services  of  a 
Router/X.25  Gateway. 

DECnet/SNA  Gateway.  A  Phase  IV  DECnet  node  that  connects  DEC- 
net-RSX  and  DECnet -VAX  nodes  to  systems  in  an  IBM  SNA  network  to 
perform  remote  job  entry,  3270  terminal  emulation,  or  task-to-task  communi- 
cation. There  is  also  software  provided  for  Gateway  management  tasks.  The 
DECnet/SNA  Gateway  is  implemented  in  two  ways: 

•  As  a  node  connected  to  an  Ethernet 

•  As  a  node  connected  to  a  Phase  IV  DECnet -RSX  or  DECnet -VAX  node  in  a 
wide  area  network. 

In  both  implementations,  the  functions  are  the  same:  remote  job  entry,  3270 
terminal  emulation,  application  programming  with  an  IBM  program,  and 
Gateway  management.  Refer  to  documentation  for  each  ser\er  product  de- 
scribed in  this  section  for  more  detailed  informatitm. 

General  purpose  nodes  perform  a  variety  of  functions  that  are  discussed  in 
Chapters  4  through  9  of  this  manual.  All  Phase  IV  general  purpose  nodes 
except  PRO/DECnet  can  run  in  either  a  wide  area  or  an  Ethernet  envinm- 
ment  unless  otherwise  specified.  The  discussions  in  this  chapter  on  environ- 
ments, node  routing  capabilities,  and  DECnet  phases  that  do  not  specifically 
address  server  nodes  apply  to  general  purpose  nodes. 

3.3    Line  and  Circuit  Characteristics 

Network  nodes  in  a  wide  area  network  can  be  connected  using  point-to-point 
or  multipoint  lines  and  circuits.  Ethernet  nodes  are  connected  by  means  of  a 
bus  topology  (as  noted  in  Section  3.1.2).  The  type  of  line/circuit  you  have 
between  two  nodes  can  have  a  marked  effect  on  access  capabilities.  For  exam- 
ple, data  on  a  point-to-point  line/circuit  between  two  nodes  can  travel  some- 
what faster  than  data  that  must  be  transferred  over  a  multipoint  line/circuit. 

A  point-to-point  line  connects  two  nodes  using  a  single  circuit.  In  a  point-to- 
point  connection,  nodes  always  have  access  to  the  communications  path  link- 
ing them  together. 
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A  multipoint  line  is  shared  by  more  than  two  nodes  (see  Figure  2  1).  Kach 
node  communicates  over  the  line  usinj;  a  separate  circuit.  One  node  on  the 
line,  called  the  control  station,  controls  access  to  the  shared  communications 
path;  the  other  nodes  on  the  line  are  known  as  tributaries. 

The  way  that  each  node  gets  to  use  the  communications  path  in  a  multipoint 
connection  is  through  a  method  called  polling.  In  polling,  the  contnti  station 
sends  a  message  to  each  tributary  in  an  order  prescribed  by  the  control  station 
software.  The  poll  message  asks  it  the  tributary  has  any  data  to  send.  It  the 
tributary  does  have  data  to  send,  the  control  station  allows  the  tributary  to 
transmit.  When  that  transmission  is  completed,  the  communications  path  is 
treed  and  the  control  station  polls  the  next  tributary.  It  a  tributary  has  no 
data  to  send  when  it  is  polled,  the  control  station  passes  on  and  polls  the  next 
tributary.  It  data  is  sent  to  a  tributary  from  another  tributary  or  system  in  the 
network,  it  must  first  pass  through  the  control  station  which  will  deliver  the 
data  (using  the  ntuting  mechanism)  to  the  specified  tributary  when  the  com- 
munications path  is  treed. 

A  multipoint  connection  can  be  more  economical  than  a  point-to-point  one.  as 
you  have  several  stations  communicating  over  a  single  line.  However,  you  may 
not  always  have  access  to  the  communications  path  when  you  need  it. 

Kthernet  nodes  are  linked  in  a  bus  topology.  This  means  that  Kthernet  cir- 
cuits use  a  common  communications  line  -  the  Kthernet  cable.  The  tech- 
nique by  which  each  user  accesses  the  Kthernet  communications  path  is 
called  Carrier  Sense  Multiple  Access  with  Collision  Detection  ((\SMA/('I)). 

Essentially.  (\SMA/(T)  states  'hat  every  communications  device  associated 
with  a  node  on  the  cable  must  listen  for  data  traific.  If  the  line  is  busy,  users 
must  wait  until  it  is  clear  to  transmit  data.  If  the  line  is  clear.  ever>-  user  on 
the  cable  has  equal  access  rights  to  it.  There  is.  however,  a  limit  on  the 
amount  of  data  a  node  can  send  at  one  time.  This  limit  prevents  any  one  node 
from  monopolizing  the  line. 

If  two  or  more  u.sers  simultaneously  try  to  transmit  data  on  the  cleared  line,  a 
collision  ol  data  will  occur.  Kach  node  senses  the  collision  condition,  stops  the 
transmi-  ion.  and  automatically  tries  to  retransmit  the  data  after  waiting  a 
randomly  selected  amount  ot  time.  Therefore,  all  nodes  on  the  Kthernet  cable 
have  the  same  access  \(.  it,  regardless  of  where  on  the  cable  they  are  posi- 
tioned. 
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Figure  M-9  shows  an  example  of  a  large  network  that  includes  a  wide  area 
network  joined  with  a  local  area  Kthernet  network.  As  you  can  see.  there  are  a 
variety  of  configurations  you  can  create  to  serve  many  needs  in  such  an  envi- 
ronment. Nodes  in  each  area  of  the  network  can  communicate  with  each  other 
and  combine  their  resources  to  perform  network  activities  as  an  active,  cohe- 
sive unit. 

Refer  to  the  software  product  description  (SIM))  and  installation  documenta- 
tion for  your  particular  DKCnet  systemis)  for  more  exact  < onfiguration  guide- 
lines. 
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Chapter  4 

Common  Mechanisms  in  DECnet  Functions 


After  configuring  your  system  (Chapter  3)  and  installing  it  (Chapter  10),  you 
are  ready  to  perform  a  variety  of  network  functions.  The  functions  that  you 
can  perform  with  DECnet  are  divided  into  the  following  areas  of  discussion: 

•  Task-to-task  communication  (Chapter  5) 

•  Remote  file  and  record  access  and  file  transfer  (Chapter  6) 

•  Terminal  communications  (Chapter  7) 

Chapter  8  describes  how  you  can  perform  these  functions  using  foreign  vendor 
networks  and  Chapter  9  describes  applications  environments  supported  by 
these  functions. 

All  of  the  functions  listed  have  some  common  mechanisms  at  work  within 
them,  such  as  logical  links  and  access  control.  This  chapter  discusses  those 
mechanisms. 


4.1    Logical  Links 


Every  node  runs  multiple  programs  and  processes.  Processes  or  programs  that 
want  to  communicate  with  each  other,  whether  they  are  in  the  same  or  in 
different  nodes,  need  some  way  of  establishing  contact  and  exchanging  data 
apart  from  the  confusion  and  interference  of  other  network  traffic.  To  expedite 
the  orderly  flow  of  information  between  two  programs  or  processes,  DECnet 
implements  a  mechanism  called  a  logical  link.  A  logical  link  is  a  temporary 
conversation  path  established  between  two  communicating  programs  (or  pro- 
cesses) in  a  DECnet  network.  (Logical  links  are  not  to  be  confused  with  lines 
or  circuits;  see  Section  2.2.) 
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4.1.1    When  Are  Logical  Links  Required? 


Almost  all  network  functions,  including  those  discussed  in  Chapters  5,  6,  7, 
and  8  require  the  services  of  a  logical  link  between  programs.  Some  mainte- 
nance functions,  such  as  certain  loopback  tests  and  the  down-line  loading  of 
certain  systems,  do  not  (for  example,  down-line  loading  an  RSX-llS  DECnet 
node,  which  does  not  have  mass  storage  facilities).  Logical  links  are  used  in 
the  following  types  of  connection: 

•  A  user  program  connected  to  another  user  program 

•  A  user  program  connected  to  a  DECnet  module 

•  A  DECnet  module  connected  to  another  DECnet  module 

In  the  first  type  of  connection,  the  application  programmer  specifies  a  series  of 
DECnet  calls  in  each  user  program  to  establish  and  direct  the  operation  of  the 
logical  link.  In  the  second  type  of  connection,  the  programmer  includes  calls 
that  initiate  and  control  the  link  in  the  user  program  only;  the  DECnet  mod- 
ule automatically  handles  its  end  of  the  link.  In  the  last  case,  the  creation  and 
operation  of  the  logical  link  is  a  level  removed  from  the  user;  user  program- 
ming is  not  involved  in  the  connection  at  all.  Typically,  two  DECnet  modules 
exchange  messages  based  on  information  supplied  by  their  local  system. 


4.1.2   How  to  Create  a  Logicai  Linl( 

As  mentioned  in  the  previous  section,  logical  links  are  created  by  an  interac- 
tion of  DECnet  calls  specified  in  the  two  cooperating  programs.  This  interac- 
tion is  referred  to  as  the  "handshake  procedure."  In  this  procedure,  DECnet 
calls  are  passed  between  the  two  programs  to  establish  an  agreement  to  com- 
municate. Unless  both  programs  agree,  a  logical  link  cannot  be  created. 

The  handshake  procedure  unfolds  in  a  prescribed  order.  First,  one  program, 
called  the  source  program,  issues  a  call  to  request  communication  with  a 
second  program,  called  the  target  program.  DECnet  software  in  the  source 
program's  node  carries  the  connection  request  to  DECnet  software  in  the 
target  program's  node.  (If  the  two  programs  are  in  the  same  node,  only  one  set 
of  DECnet  software  is  involved  in  establishing  connection — see  Section  4.1.3.) 

The  target  program  has  the  option  of  accepting  or  rejecting  the  source  pro- 
gram's request  for  connection.  If  the  target  program  returns  a  call  accepting 
the  connection  request,  a  logical  link  is  established  between  the  two  programs. 
At  this  point,  source  and  target  distinctions  become  irrelevant,  and  both 
programs  can  issue  calls  to  send  and  receive  data  until  either  me  of  them 
decides  to  exit  or  abort  the  connection.  If  the  target  program  returns  a  call 
rejecting  the  connection  request,  no  logical  link  is  created. 

The  individual  calls  used  to  establish  a  logical  link  and  to  exchange  data  with 
another  program  are  described  in  the  programmer's  reference  manual  for  each 
DECnet  system.  The  programming  languages  you  can  use  to  issue  these  calls 
in  each  system  are  also  listed  there.  Section  9.1.1  discusses  logical  link  pro- 
cessing in  an  applications  environment. 
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4.1.3   Behind  the  Scenes  —  DECnet  Software  and  Logical  Units 


The  information  passed  between  two  programs  in  the  handshaking  procedure 
and  in  all  communications  activity  is  intercepted  and  evaluated  by  equivalent 
DECnet  modules  in  each  node.  Information  passes  from  the  local  program  to 
the  local  DECnet  software,  from  the  local  DECnet  software  to  the  remote 
DECnet  software,  and  finally  to  the  remote  program  (as  shown  in  Figure  4-1). 
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Figure  4-1:    Logical  Links  and  DECnet 
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DECnet  software  on  each  node  examines  calls  received  from  the  local  program 
(the  program  located  on  the  same  node)  and  information  re^'eived  from  equiv- 
alent DECnet  software  on  the  remote  node.  Each  set  of  DFX'net  software  acts 
as  an  intermediary  to  field  invalid  information  and  to  pass  requests,  re- 
sponses, and  data  between  the  two  programs  in  a  manner  that  is  transparent 
to  the  end  user.  The  user  sees  only  one  program  talking  to  the  other. 

Other  actions  performed  by  DECnet  software  on  each  node  with  respect  to 
logical  links  are: 

•  Establishes  link  addresses  to  identify  each  end  of  a  logical  link 

•  Checks  to  see  whether  the  two  programs  have  valid  access  to  each  other  (see 
Secticn  4.5) 

•  Formats  outgoing  data  for  transmission  by  communication  hardware 

•  Allows  multiple  logical  links  to  be  created  over  a  single  physical  line  by 
separating  data  into  logical  link  streams 

•  Removes  incommg  data  from  logical  link  streams  and  delivers  it  to  the 
appropriate  program 

•  Assures  that  data  segments  are  delivered  in  proper  sequence  or  are  re- 
transmitted (as  described  in  Section  4.H) 

•  Implements  flow  control  in  conjunction  with  the  programs  to  make  sure  that 
there  is  enough  buffer  space  to  receive  and  store  data  (see  Section  4.4) 

The  user  is  not  aware  of  any  of  these  activities;  the  connection  between  the 
two  programs  appears  to  be  direct  and  without  mediation.  However,  if  some 
problem  occurs  in  the  connection,  the  DECnet  software  notifies  the  user  by 
means  of  an  error  or  status  message. 

4.1 .4   How  the  Program  Identifies  Logicai  Links 

A  program  can  establish  and  use  more  than  one  logical  link  at  a  time.  The 
maximum  number  of  links  that  can  run  simultaneously  in  a  single  program  is 
usually  determined  by  the  programmer  or  by  system  restrictions.  (See  your 
programmer's  reference  manual  for  details  on  the  requirements  of  your  partic- 
ular system.) 

In  view  of  this,  a  program  needs  some  way  to  differentiate  between  the  multi- 
ple logical  links  that  may  be  running  within  it.  This  is  handled  by  having  each 
program  specify  a  unique  link  identifier  during  every  handshake  procedure  to 
identify  the  link  that  may  be  created.  The  link  identifier  defines  a  link  only 
within  the  context  of  a  particular  program;  two  cooperating  programs  do  not 
have  to  specify  the  same  link  identifier  for  the  same  link. 

The  DECnet  software  on  each  node  takes  the  link  identifier  specified  by  its 
local  program,  and  together,  both  sets  of  DECnet  software  agree  on  a  pair  of 
link  addresses  that  they  associate  with  a  particular  link.  Link  addresses  are 
meaningful  only  to  the  DECnet  software;  they  are  transparent  to  the  end  user. 
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4.1.5    Multiple  Logical  Links  within  a  Program 

A  single  program  can  establish  logical  links  that  conuminicatc  with  several 
programs,  or  a  single  program  can  establish  several  logical  links  with  the  same 
program  to  exchange  data  intended  lor  diflerent  purposes.  For  example,  two 
programs  can  establish  two  logical  links  between  them;  one  link  can  be  used 
to  transmit  transaction  data,  while  the  other  can  be  used  to  transmit  control 
information. 


4.2    Data  Types 


Data  that  you  send  over  a  logical  link  is  distinguished  as  either  normal  data  or 
interrupt  data.  Normal  data  constitutes  the  subject  matter  ot  most  data  ex- 
changes between  two  programs.  For  example,  user  data  transmitted,  such  as  a 
list  of  messages,  and  the  responses  sent  by  the  receiving  program,  would 
constitute  normal  data  How.  To  interrupt  this  How  of  normal  data,  either 
program  can  send  interrupt  data.  Interrupt  data  is  typically  high  priority 
information  signaling  the  occurrence  of  some  event  requiring  immediate  at- 
tention. Interrupt  data  breaks  through  the  normal  data  How.  The  means  of 
delivering  interrupt  data  are  system  and  program  dependent,  but  the  receiver 
usually  reads  it  before  accepting  any  normal  data  that  mav  be  pending. 


4.3    Segment  Acknowledgment  and  Retransmission 

The  DKCnet  software  that  manages  each  end  of  a  logical  link  guarantees: 

•  That  all  transmitted  data  is  delivered  to  the  destination  node  in  proper 
sequential  order 

•  That  all  data  received  by  DKCnet  software  on  the  destination  node  is  given 
to  the  target  program  in  the  proper  sequence 

To  guarantee  proper  segment  set^uencing.  DKCnet  software  numbers  the  seg- 
ments it  transmits  over  a  link.  The  receiving  DKCnet  software,  using  the 
transmit  numbers  for  identificatij>n.  must  acknowledge  the  delivery  of  the 
segments.  If  a  segment  is  not  acknowledged  within  a  certain  period  ol  time, 
the  sending  DKCnet  software  retransmits  it. 

DKCnet  software  assigns  a  separate  set  ot  transmit  numbers  to  interrupt 
messages.  The  separate  sets  of  numbers  logically  divide  normal  data  and 
interrupt  data  into  separate  data  streams  within  the  logical  link. 

The  detailed  execution  of  segment  acknowledgment  and  retransmission  varies 
def)ending  on  the  software  implementations  involved.  However,  despite  varia- 
tions in  detail,  all  DKCnet  software  uses  these  mechamsms  to  guarantee 
delivery  of  all  transmitted  segments  and  to  ensure  that  the  segments  are 
delivered  in  the  f)roper  sequence. 
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4.4    Flow  Control 


Network  programs  and  DECnet  software  both  require  a  certain  amount  of 
buffer  space  for  temporary  message  storage.  For  example,  DECnet  software 
keeps  a  copy  of  every  message  it  sends  over  a  link  until  the  receiver  acknowl- 
edges receipt  of  the  message.  At  the  program  level,  buffer  space  is  necessary  to 
hold  inbound  messages  waiting  to  be  processed.  DECnet  software  and  pro- 
grams need  buffer  space  for  other  purposes  as  well,  depending  on  the  applica- 
tion and  the  DECnet  implementations. 

Without  some  kind  of  control,  message  traffic  can  easily  cause  available 
buffer  space  to  overflow.  If  this  happens,  communications  overhead  is  in- 
curred because  a  message  must  be  present  at  specified  intervals  until  the 
destination  node  can  accept  it.  To  prevent  this,  the  programs  and  DECnet 
software  exercise  flow  control.  In  most  implementations,  programs  coordinate, 
send,  and  receive  calls.  DECnet  software  transmits  data  from  a  source  pro- 
gram only  if  the  target  program  has  issued  a  receive  call.  In  some  implementa- 
tions, however,  the  target  node's  DECnet  software  must  merely  have  suffi- 
cient buffer  space  available  to  hold  the  data.  In  either  case,  the  DECnet 
software  handling  the  link  between  the  programs  ensures  that  the  appropriate 
condition  is  satisfied  before  any  data  is  actually  sent. 

The  DECnet  software  modules  on  each  node  exchange  link  service  messages 
to  request  and  convey  information  about  the  availability  of  buffer  space  and 
about  other  conditions  that  pertain  to  data  flow  on  the  link.  The  detailed 
operation  of  flow  control  depends  on  the  DECnet  nodes  on  the  link.  A  major 
aid  in  ensuring  optimum  network  performance  over  links  and  between  nodes 
is  a  network  product  called  Observer  (discussed  in  Section  11.2). 


4.5    Access  Control 


Most  DECnet  nodes  have  some  type  of  access  control  mechanism  that  exam- 
ines logical  link  requests  to  prevent  unauthorized  access  of  node  resources. 
Typically,  petitioning  programs  must  specify  information  similar  to  the  infor- 
mation needed  to  log  on  to  the  remote  system.  For  example,  a  program  may 
have  to  specify  an  authorized  user  name  or  account  and  password  in  order  to 
gain  entrance  to  a  task  on  the  remote  node.  DECnet  software  at  the  remote 
node  verifies  the  information  given  and  decides  whether  or  not  to  allow  access. 
In  task-to-task  communication,  you  must  specify  access  control  information 
in  a  special  parameter  when  you  request  a  logical  link  connection  (see  Section 
5.2).  In  remote  file  access  (Section  6.1.4)  and  in  terminal  communications 
(Section  6.2.1),  you  must  include  this  information  in  the  file  specification. 
(File  specifications  differ  for  each  type  of  DECnet  system;  therefore,  refer  to 
the  programmer's  reference  manual  for  your  DECnet  system  to  determine 
correct  syntax.) 

Access  control  information  may  not  be  required  for  every  network  function.  To 
determine  what  information  is  needed  and  when,  consult  the  system  manager 
at  the  remote  node  to  which  you  are  seeking  access.  Access  control  informa- 
tion is  initially  established  during  installation,  and  can  be  dynamically  modi- 
fied on  most  systems  by  the  system  manager. 
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Chapter  5 

Task-to-task  Communication 


DECnet  enables  two  programs  within  a  network  to  perform  task-to-task  com- 
munication —  that  is.  to  exchange  data  over  a  logical  link.  For  example,  an 
HSX-llM  program  can  use  local  DECnet- RSX  facilities  to  communicate 
with  a  program  running  in  a  DECnet-VAX  node.  (There  is  no  DECnet  user 
interface  for  task-to-task  communication  using  the  Professional  300  series 
personal  computer.  Therefore,  the  rest  of  this  discussion  may  not  be  relevant 
for  PRO/DECnet  users.) 

In  most  DPXnet  implementations,  performing  task-to-task  communication  is 
similar  to  performing  input/output  (I/O).  The  logical  link  between  the  two 
programs  is  like  an  I/O  channel  over  which  both  programs  can  send  and 
receive  data.  (Refer  to  system-specific  documentation  for  details  on  how  a 
particular  operating  system  implements  I/O  operations.) 


5.1    DECnet  Task-to-task  Calls 

DECnet  calls  are  written  into  cooperating  task-to-task  programs  to  enable 
them  to  communicate  with  each  other.  These  calls  activate  routines  request- 
ing the  local  DECnet  software  in  each  node  to  perform  specific  functions  such 
as  the  creation  and  control  of  a  logical  link  (see  Chapter  4). 

The  form  of  the  DECnet  calls  that  a  programmer  specifies  depends  on  the 
programming  language  being  used;  calls  can  actually  be  calls,  macros,  or 
system  directives.  However,  the  DECnet  task-to-task  capability  translates 
each  of  these  call  types  into  the  same  set  of  DECnet  software  messages  regard- 
less of  the  language  in  which  they  are  pn^grammed.  For  example,  the  DECnet 
software  sends  the  same  type  of  message  to  the  remote  node  in  response  to  a 
FORTRAN  connect  request  call  as  it  does  in  response  to  a  connect  request 
macro.  Therefore,  you  do  not  have  to  be  concerned  about  what  programming 
languages  are  supported  by  the  remote  node  when  you  write  a  task-to-task 
program. 
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You  do,  however,  have  to  be  concerned  about  what  languages  are  supported 
by  the  local  node  since  not  all  operating  systems  support  the  same  languages 
and  all  languages  do  not  support  task-to-task  communication.  Refer  to  the 
programmer's  reference  manual  for  your  particular  DECnet  system  for  a  list 
of  the  programming  languages  you  can  use  for  task-to-task  communication. 

Every  DECnet  task-to-task  program  can  issue  calls  to  perform  the  following 
functions: 

•  Request  a  logical  link 

•  Receive  a  logical  link  request 

•  Accept  or  reject  a  logical  link  request 

•  Send  data 

•  Receive  data 

•  Send  interrupt  data 

•  Receive  interrupt  data 

•  Terminate  the  logical  link 

Depending  on  the  local  system  and  the  language  used,  there  is  not  always  a 
one-to-one  correspondence  between  the  call  issued  and  one  of  the  above  steps. 
In  some  cases,  a  program  must  issue  three  separate  calls  to  create  a  logical 
link:  in  other  cases,  a  program  needs  to  issue  only  one  call. 


5.2   Requesting  a  Logical  Linic 

The  first  thing  you  need  to  do  to  establish  task-to-task  communication  is  to 
request  a  logical  link.  To  do  this,  you  issue  a  connect  request  call  according  to 
the  language  conventions  of  your  particular  DECnet  system.  (This  is  the  first 
step  m  the  handshake  procedure  described  in  Section  4.1.2.) 

The  connect  request  call  must  provide  network  addressing  information  that 
identifies  who  is  sending  the  message  and  who  should  receive  it.  You  can 
specify  this  addressing  information  in  the  source  program  either  by  building  a 
special  data  area  (called  a  connect  block)  or  by  specifying  an  ASCII  string 
called  a  network  specification. 


• 
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5.2.1    Building  a  Connect  Block 

Most  DECnet  task-to-task  call  sequences  include  one  or  more  calls  to  build  a 
connect  block.  You  specify  parameters  to  the  connect  block  call(s)  that  iden- 
tity the  source  and  target  programs.  These  parameters  will  include  all  or  part 
of  the  following  information: 

•  Link  Identifier.  This  identifier  differentiates  the  requested  link  from  any 
other  links  currently  being  used  by  the  source  program  (see  Section  4.1.4  for 
a  discussion  of  logical  link  identifiers).  If  the  connect  request  succeeds,  the 
source  program  uses  the  link  identifier  to  address  data  to  be  sent  over  the 
link.  The  source  program's  link  identifier  is  called  by  various  names,  de- 
pending on  the  operating  system  implementing  DECnet.  Check  the  pro- 
grammer's reference  manual  for  your  system  to  determine  what  the  link 
identifier  is  called  on  your  system. 

•  Target  node  identifier.  This  identifier  can  be  a  unique  node  address  that 
distinguishes  the  node  from  all  others  in  the  network,  or  it  can  be  a  locally 
defined  node  name  that  the  local  DECnet  software  translates  into  a  unique 
node  address  (see  Section  2.1). 

•  Object  type  or  name.  Object  is  another  term  for  a  network  program.  A 
network  program  or  object  has  a  special  identifier  for  use  in  network  calls. 
This  identifier  consists  of  an  object  type  and/or  an  object  name.  Section 
5.2.1.1  explains  the  significance  of  the  object  type  and  name.  Figure  5-1 
shows  how  objects  are  addressed. 

•  Access  control  information.  This  information  describes  the  source  pro- 
gram and  includes  a  user  identification,  a  password,  and  optionally,  an 
account  number.  The  information  is  equivalent  to  the  data  a  user  supplies 
when  logging  on  to  a  system.  In  most  implementations,  the  target  program 
uses  this  information  as  a  factor  in  its  decision  to  accept  or  reject  the 
connect  request. 

•  Optional  user  data.  A  source  program  usually  has  the  option  of  sending  16 
bytes  of  data  to  the  target  program  as  part  of  a  logical  link  connect  request. 

When  you  finish  building  the  connect  block  using  the  calKs),  macro! s),  or 
directive(s)  appropriate  for  your  system  and  language,  you  can  specify  the 
label  or  address  of  that  connect  block  in  the  source  program  as  a  parameter  to 
a  connect  request  call.  This  provides  network  addressing  informati(m  you 
need  when  requesting  a  logical  link. 
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5.2.1.1  Object  Types  and  Names  —  As  mentioned  in  the  previous  section,  one 
of  the  parameters  you  specify  in  a  connect  hlock  is  an  object  type  or  name.  An 
object  type  or  name  identifies  —  to  the  local  DECnet  software  —  a  program 
that  provides  a  known  service  and  uses  known  protocols.  For  example,  object 
17  (FAD  provides  remote  file  access. 

In  most  DECnet  implementations,  a  profjram  must  declare  its()l)ject  type  and 
name  to  the  DECnet  software  in  order  to  be  eligible  to  receive  link  requests.  In 
some  implementations,  a  system  manager  can  use  a  DECnet  command  at  a 
terminal  to  declare  a  program's  object  type  and  name,  ((^heck  your  program- 
mer's reference  manual  to  find  out  how  objects  are  specified  on  your  system. ) 

The  object  name  may  be  a  special  network  name  for  the  program,  or  it  may  be 
the  same  name  by  which  the  program  is  known  to  the  local  operating  system. 
Object  types  and  names  are  used  by  the  source  program  in  a  connect  request 
to  specify  the  target  program  with  which  it  wants  to  communicate.  This  is 
done  using  one  of  two  formats: 

•  An  object  type  equal  to  0  and  an  ASCII  name 

•  An  object  type  equal  to  a  positive  integer  (from  1  to  255)  and  a  null  name 

The  first  format  identifies  a  program  by  name,  whereas  the  second  format 
identifies  a  program  by  numeric  object  type. 

To  address  a  target  program,  a  connect  request  specifies  either  a  name  or  an 
object  type,  but  not  both.  The  first  format  —  object  type  0  plus  name  —  is 
commonly  used  to  address  user-written  network  programs.  To  use  this  format 
in  a  connect  request,  a  source  program  must  know  the  target  program's  de- 
clared object  name.  Note  that  the  maximum  length  allowed  for  a  name  de- 
pends on  the  local  node's  operating  system. 

The  second  format  provides  an  abbreviated  means  of  identifying  a  frequently 
used  network  function,  usually  a  specific  DECnet  module.  A  specific  type 
always  represents  the  same  generic  function  within  a  network,  even  if  the 
program  that  actually  performs  the  function  has  a  different  name  at  each 
node.  In  this  way,  a  network  program  can  address  a  function  without  knowing 
the  function's  name  in  the  target  node. 

Digital  reserves  a  range  of  object  types  for  DECnet  system  programs.  Types 
within  this  range  are  used  consistently  across  all  DECnet  implementations  to 
refer  to  the  same  functions.  The  programmer's  reference  manual  for  each 
DECnet  implementation  lists  the  object  types  reserved  for  DECnet  use. 

Unreserved  types  can  be  used  for  user-written  network  programs.  For  exam- 
ple, in  a  user-written  transaction-processing  application,  each  node  might 
have  a  resident  program  for  recording  statistics  on  transactions  performed 
within  the  last  24  hours.  The  application's  designer  could  choose  an  unre- 
served object  type  to  identify  all  such  programs  throughout  the  network. 

Figure  5-1  illustrates  the  object  identifiers  for  several  programs  in  Node  A  and 
Node  B. 


5-4       Introduction  to  DECnet 


NODE  A 


NODE  B 


AY  and  BEE  are  user-written 
programs  identified  by  name  in 
"connect  requests  addressed  to 
them 


CEE  and  DEE  are  user-written 
programs  that  perform  the  same 
function  in  their  r     pective  nodes 
as  part  of  a  network  application 
•  They  are  both  identified  by  object 
type  200  in  connect  requests 
addressed  to  them   200  is  m  the 
range  of  types  reserved  for 
customer  use 


The  two  FAL  programs  are 
Digital-supplied  modules  that 
•  receive  all  f;le  access  requests  from, 
remote  nodes  A  FAL  module  is 
always  identified  by  obiect  type  17 


LEGEND 


Network  program 

The  object  type  and  name  by  which  the  local 
NSP  module  knows  the  program 


Figure  5-1 :    Addressing  Network  Objects 


5.2.1.2  Access  Controi  —  Access  control  is  implemented  in  different  ways  on 
different  systems.  Refer  to  documentation  for  your  system  for  specific  infor- 
mation. A  general  discussion  of  access  control  is  provided  in  Section  4.5. 


5.2.2    Network  Specifications 

If  you  do  not  provide  network  addressing  information  for  the  connect  request 
using  a  connect  block,  you  must  provide  that  information  in  a  netw(irk  specifi- 
cation. (.Some  DKCnet  sy.stems  require  a  network  specification  instead  of  a 
connect  block.  Refer  to  documentation  specific  for  your  DECnet  system  to 
find  out  if  and  how  network  specifications  must  be  u.sed.) 
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A  network  specituatioii  is  an  ASCII  slriji^  spciitit'd  in  the  coniu'ct  reciuest 
ilselt.  Like  the  loniu'ct  hlnik.  it  iiicludi's  a  target  node  idcntilier.  access 
lontnti  iiit(»rriiatii)ti.  and  a  tarj:i't  ohji-ct  lypt'  or  iiaiiu'.  (I)K('net  20  lU'tvvork 
sp('(  iliiations  can  iiulude  optional  data.) 

5.3    Accepting/Rejecting  a  Logical  LiriL  Request 

The  source  DKCiU't  sottwarc  forwards  the  connect  re(|uest  t(t  the  node  speci- 
fied in  the  connect  block  (»r  network  specification.  The  DKCnet  software  in 
the  target  node  I'hecks  that  the  program  addressed  in  the  connect  recjuest  is  a 
\ahd  object  and  then  \erifies  the  source  program's  identification  (see  Section 
.").2.1i.  Il  the  target  program  i>  a  known  object  and  any  recjuired  verification 
checks  out.  the  target  !)K('net  software  deh\ers  the  connect  rec^uest  to  the 
target  program. 

After  examining  the  incoming  cotinecf  recjuest.  the  target  program  either  ac- 


cepts or  reject >  i 


I.  i\ 


ransparent  comm 


unication  in  DKCnet    WAX  and  tfie 


concise  COBOL  interface  in  DKCnet  Fl  do  not  allow  a  program  to  reject  a 
connect  recjuest.  See  system-specific  documentation  for  details  on  how  each 
system  handles  connection  re(iuest>.)  Tfie  target  node's  DKCnet  software  for- 
wards the  appropriate  response  back  to  the  source  node.  The  target  program 
usually  has  the  option  of  sending  H)  b\ tes  of  (lata  ahtng  with  the  acceptance  or 
rejection  (  f  the  link.  For  example,  a  connect  reject  response  might  include 
data  that  lelU  the  -ource  program  wh\  the  connect  recpiest  was  not  accepted. 

If  the  target  |)rogram  agrees  to  the  (onnection,  it  specifies  its  own  logical  link 
identifier  m  a  call  accepting  the  recjuest  to  create  a  logical  link. 


5.4    Sending  and  Receiving  Data 

Once  the  target  node  accepts  the  connect  recjuest  and  a  logical  link  has  been 
established,  either  program  can  send  and  receive  data  using  the  assigned 
logical  link  identifiers  as  address  parameters  on  each  message.  They  can 
ahernately  send  and  receive,  or  they  can  send  and  receive  simultaneously. 

Two  kinds  of  data  can  be  sent  over  a  logical  link:  normal  data  and  interrupt 
data  .As  Section  I. J  explains,  normal  data  makes  up  the  sul)iect  matter  of  the 
programs"  dialog,  whereas  interrupt  data  coiuevs  special  high  priority  infor- 
mation. 


• 


5.4.1    Normal  Data 

To  convey  normal  data  over  the  link,  a  source  program  issues  one  or  more  calls 
to  send  the  data,  and  a  target  j)rogram  issues  one  or  more  calls  to  receive  it. 
The  DKCjiet  software  at  the  source  node  will  not  transmit  data  unless  the 
target  program  has  already  issued  a  receive  call  Kach  receive  call  allocates 
the  buffer  space  needed  bv  the  target  program  to  store  the  drita.  Figure  ')  2 
outlines  this  procedure. 
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Some  DECnet  implementations  allow  the  source  DECnet  software  to  transmit 
data  over  any  logical  link  as  long  as  the  target  DECnet  software  has  access  to 
enough  system  buffer  space  to  hold  the  data.  The  DECnet  software  at  the 
target  node  then  delivers  the  data  it  has  received  when  the  appropriate  target 
program  allocates  its  own  buffer  space  by  issuing  one  or  m.ore  receive  calls. 

Regardless  of  the  implementations  involved,  the  DECnet  software  in  the 
source  and  target  nodes  exchange  link  service  messages  to  determine  whether 
the  target  program  is  prepared  to  receive  a  message.  This  precaution  is  part  of 
DECnet's  flow  control  mechanism  (de^v  ribed  in  Section  4.4). 
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Figure  5-2:    Transmitting  Normal  Data 


5.4.2   Interrupt  Data 

Interrupt  data  can  consist  of  up  to  16  bytes  of  information  to  be  delivered 
immediately  to  the  target  program.  If  the  target  DECnet  software  has  a  queue 
of  normal  data  already  received  but  not  yet  processed,  the  interrupt  data  is 
placed  either  at  the  head  of  that  queue  or  in  a  separate  queue  that  the  target 
program  can  access  without  first  reading  the  notr  '\\  data. 
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5.5   Terminating  the  Link 


Either  program  can  issue  a  call  at  any  time  to  terminate  the  link  in  one  of  two 
ways.  One  way,  which  disconnects  the  Hnk  in  an  orderly  fashion,  is  normally 
used  by  a  program  to  terminate  a  sessi(m  that  has  proceeded  as  expected.  Ali 
pending  transmissions  are  completed  before  the  link  is  dissolved.  The  pro- 
grammer must  decide  which  of  the  two  programs  disconnects  under  normal 
circumstances.  When  discussing  these  orderly  disconnections,  the  various 
DECnet  user's  manuals  call  them  disconnects  or  synchronous  disconnects. 

The  second  way  to  disconnect  forces  the  link  to  be  terminated  whether  or  not 
the  remote  DECnet  .sottware  has  acknowledged  previously  transmitteo  data. 
In  most  programmer's  manuals,  this  method  of  disconnecting  the  link  is 
called  aborting  the  link.  When  the  caller's  DECnet  software  receives  notifica- 
tion to  abort  a  link,  it  cancels  ail  messages  waiting  to  be  transmitted  over  the 
Imk.  A  program  may  choose  to  abort  in  response  to  some  unusual  system 
event,  such  as  an  impending  emergency  shutdown.  Whether  a  program  simply 
disconnects  or  aborts  the  link,  it  can  simultaneously  send  up  to  16  bytes  (if 
data  to  the  other  program. 


• 
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Chapter  6 

Remote  File  and  Record  Access 


Using  DECnet,  a  program  in  one  node  can  access  a  file  in  another  node, 
despite  differences  in  the  operating  and  file  systems  of  the  two  nodes.  This 
remote  file  access  capability  has  the  following  applications: 

•  A  user-written  program,  can  incorporate  DECnet  I/O  calls  that  allow  it  to 
perform  the  following  record- level  operations:  (1)  open  and  close  a  remote 
file  (2)  create  or  delete  a  remote  file  (3)  read  from  or  write  records  to  a 
remote  file.  These  operations  are  described  in  Section  6.1. 

•  A  terminal  user  can  run  a  DECnet  utility  or  issue  a  system  command  to 
manipulate  remote  files  as  follows:  (1)  transfer  (copy)  files  to  or  from  remote 
nodes  (2)  delete  remote  files  (3)  submit  and  execute  command  files  at  a 
remote  node  (4)  append  files  to  local  or  remote  files  (5)  list  remote  direc- 
tories (6)  queue  files  to  a  remote  printer.  These  operations  are  described  in 
Section  6.2. 

Like  other  DECnet  functions,  remote  file  access  requires  the  cooperation  of 
two  network  programs,  which  exchange  a  series  of  DECnet  messages.  A  pro- 
gram in  one  node  issues  a  call  requesting  remote  file  access.  This  call  is 
translated  into  one  or  more  DECnet  messages  by  the  local  DECnet  software 
and  then  sent  to  a  program  in  the  remote  node.  The  program  in  the  remote 
node  receives  the  file  access  request  messages  and  translates  them  into  a  form 
recognizable  to  its  file  system.  If  the  request  is  accepted,  the  file  operations 
are  performed. 

As  in  task-to-task  comi^unication,  the  two  programs  must  establish  a  logical 
link  before  they  can  begin  communicating.  See  Section  4.1  for  information  on 
logical  links. 
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In  the  context  of  remote  file  access,  the  program  that  requests  remote  file 
access  is  called  the  source  program,  and  a  DECnet  system  program  that 
receives  the  request  is  called  the  target  program.  Depending  on  the  type  of 
DECnet  system  you  are  using,  the  source  program  can  he  one  of  the  following 
types  of  software  modules  (refer  to  sysi   m-specific  documentation): 

•  A  version  of  the  Network  File  Transfer  (NFT)  utility 

•  A  system  command  such  as  the  COPY  command 

•  A  user-written  program  that  accesses  remote  files  via  calls  to  DECnet 
subroutines  or  to  file  access  subroutines  provided  by  the  local  file  system 

The  target  program  is  a  DECnet  utility  (generally  referred  to  as  a  file  access 
listener)  that  translates  file  access  requests  it  receives  into  calls  to  its  local  file 
system.  The  target  program  is  also  responsible  for  sending  any  resulting  file 
data  back  to  the  source  program.  File  data  sent  by  the  target  program  is  first 
received  by  DECnet  software  which  presents  it  to  the  source  program  in  a 
format  compatible  with  its  local  file  system. 

File  data  can  flow  in  either  direction  between  the  source  program  and  a  target 
program.  The  file  accessed  can  reside  on  a  mass  storage  device  like  a  disk  and 
it  can  be  directed  to  an  I/O  device  such  as  a  line  printer  or  a  terminal.  The 
actual  file  operations  that  a  source  program  can  perform  depend  on  the  file 
systems  local  to  both  nodes.  See  the  programmer's  reference  manual  associ- 
ated with  the  particular  systems  involved  in  remote  file  access  for  detailed 
information. 

Section  6.1  discusses  how  a  program  can  issue  calls  to  gain  access  to  remote 
files.  Section  6.2  describes  how  to  access  remote  files  from  a  terminal.  See 
Section  9.2  and  9.3  for  examples  of  DECnet's  remote  file  access  capability  in 
an  applications  environment. 


6.1    Programming  Remote  File  Access 

To  gain  access  to  a  remote  file,  a  user  program  incorporates  DECnet  I/O  calls, 
which  activate  remote  file  access  subroutines.  The  function  of  these  sub- 
routines is  to  build,  send,  and  interpret  DECnet  file  access  messages.  All 
DECnet  systems  allow  you  to  perform  the  following  operations  on  a  remote 
file: 

•  Open  an  existing  file 

•  Create  a  new  file 

•  Read  records  from  a  file 

•  Write  records  to  a  file 

•  Close  a  file 

•  Delete  a  file 
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In  addition  to  these  operations,  specific  DECnet  systems  allow  user  programs 
to  manipulate  remote  files  in  other  ways.  The  programmer's  reference  manual 
for  each  system  discusses  what  operations  are  available  and  how  you  specify 
DECnet  calls  for  remote  file  access  on  a  specific  system.  Sections  that  follow 
discuss  factors  in  preparing  to  write  remote  tile  access  programs  that  apply  to 
all  DECnet  implementations. 


6.1.1    File  System  Capabilities 

A  programmer  needs  to  be  familiar  with  the  file  .system  resident  at  the  target 
node.  File  organization,  access  modes,  and  other  characteristics  are  depend- 
ent on  the  type  of  file  system  that  each  operating  system  supports.  When  the 
local  and  remote  nodes  have  the  same  operating  and  file  systems,  program- 
ming remote  access  is  similar  to  programming  local  I/O  operations.  However, 
when  the  access  operation  bridges  different  types  of  operating  systems,  the 
programmer  faces  certain  variables  and  restrictions. 

Generally,  the  theory  of  the  lowest  common  denominator  applies:  a  source 
program  can  perform  those  functions  that  its  local  language  provides  and  that 
the  remote  file  system  supports.  For  example,  a  VAX/VMS  program  cannot 
use  all  the  remote  access  functions  provided  by  DECnet-VAX  if  the  target 
node  runs  RSX-llM. 

By  cross-checking  the  file  system  characteristics  with  the  available  remote 
access  calls,  a  programmer  can  find  out  the  kinds  of  file  operations  that  are 
possible  between  two  different  DECnet  implementations.  This  information  is 
provided  in  the  programmer's  reference  manual  for  each  DECnet  system. 


6.1.2    Initiating  Remote  Access 

Like  task-to-task  communication,  remote  file  access  requires  a  handshake 
sequence  at  the  beginning  of  the  operation.  Not  only  does  DPXnet  software 
set  up  a  logical  link  between  the  source  and  target  programs,  it  also  exchanges 
DECnet  file  access  messages  to  prepare  for  the  file  operation  that  will  be 
performed  over  the  link. 

This  extended  handshake,  which  is  transparent  to  the  source  program,  hap- 
pens automatically  when  the  program  issues  a  call  to  open  a  remote  file.  The 
form  of  the  open  call  varies  from  system  to  system  and  from  language  to 
language,  but  the  call  always  provides  much  of  the  information  exchanged  in 
the  handshake.  I'sing  the  information  supplied  by  the  call,  as  well  as  system- 
supplied  data  about  the  local  file  system,  the  remote  access  subroutines  gen- 
erate DECnet  file  access  messages  addressed  to  the  target  program.  In  re- 
sponse, the  target  program  sends  back  DFlCnet  file  access  messages  to  define 
characteristics  of  its  local  file  svstem. 


Remote  File  and  Record  Access       6-3 


For  most  remote  access  operations,  the  open  call  issued  by  the  source  program 
passes  the  followi'     information  to  subroutines  within  the  local  file  system: 

•  A  file  specifical    n 

•  Access  control  information 

•  Characteristics  of  the  file  to  be  accessed 

Depending  on  the  open  call's  particular  function  —  for  example,  open  for 
reading  or  open  for  appending  —  the  call  passes  other  information  as  well. 


6.1.3   The  File  Specification 

The  file  specification  identifies  the  remote  file  to  be  accessed.  Because  the 
remote  ♦'le  system  actually  carries  out  the  requested  file  operation,  the  pro- 
grammer must  know  how  the  file  is  identified  by  users  on  the  node  where  the 
file  resides.  Refer  to  the  programmer's  reference  manual  for  the  source  and 
target  systems  for  file  specification  syntax. 


• 


6.1.4   Access  Controi  Information 

Access  control  information  identifies  the  program  to  the  remote  system  and 
consists  of: 

•  A  user  identification  code  or  name 

•  A  pa.ssword  associated  with  the  user  identification 

•  Additional  accounting  information  as  required  by  the  remote  system 

If  this  information  matches  an  account  or  guest  account  entry  in  the  remote 
system's  user  file,  the  program  gains  access  to  that  system's  resources.  Like 
the  file  specification,  the  access  control  information  must  be  recognizable  to 
the  remote  system  and  therefore  specified  according  to  its  syntax. 

(Jaining  access  to  the  remote  .system  does  not  guarantee  that  requested  file 
operations  will  succeed.  In  most  Digital  operating  .systems,  each  file  has  a 
corresponding  protection  code  that  determines  the  types  of  access  allowed  to 
defined  groups  of  users.  The  user  identification  —  a  code  or  a  name  —  speci- 
fied by  the  accessing  program  determines  the  program's  group  category  and 
therefore  determines  the  types  of  access  it  can  make  to  each  file. 
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6.1.5    File  Characteristics 

File  characteristics  define  the  tile  to  be  accessed  in  the  t'ollowing  ways: 

•  Access  method  —  sequential  or  random.  The  program  requesting  file 
access  indicates  how  it  will  access  the  tile.  All  Digital  file  systems  support 
sequential  access  in  which  each  I/O  operation  reads  or  writes  the  next  rec- 
ord. Selected  file  systems  permit  random  access,  which  allows  the  program 
to  access  a  specific  jecord  anywhere  in  the  file. 

•  File  organization  —  sequential,  relative,  or  indexed.  Sequential  file  or- 
ganization means  that  records  in  a  file  aie  arranged  one  after  the  orher.  This 
organization  is  supported  tor  all  types  of  devices.  Relative  file  organization 
means  that  records  within  a  file  are  identified  by  a  relative  record  number. 
This  number  identifies  the  record's  position  relative  to  the  beginning  of  the 
file.  Indexed  organization  (RMS  only)  is  a  complex  file  structure  that  allows 
both  sequential  and  rand(jm  access  and  uses  record  keys  for  identification. 
The  keys  used  to  identify  individual  records  are  defined  at  file  creation. 
Relative  organization  is  supported  only  for  disk  devices. 

•  Data  type  —  ASCII  or  image.  \SC\l  data  is  subject  to  formatting  conver- 
sion by  the  DKCnet  software,  depending  on  the  data's  record  attributes  (see 
below).  Image  data  is  a  stream  of  bits  to  which  the  DKCnet  .software  applies 
no  interpretation. 

•  Record  attributes.  This  characteristic  indicates  th?  type  of  vertical  format 
control  that  applies  to  th^  file. 

•  Record  format  —  fixed  length,  stream,  variable  length,  or  variable  with 
fixed  length  control  (VFC).  This  characteristic  indicates  the  way  the  re- 
cords are  formatted  within  the  file.  A  WV  record,  supported  by  RMS  only, 
includes  a  fixed  length  control  field  in  addition  to  the  variable  length  data 
portion. 


6.2    Accessing  Remote  Files  ?rom  a  Terminai 

All  DECnet  implementations  support  terminal-based  access  of  some  kind  to 
remote  files.  Some  DKCnet  implementations  use  system  commands  such  as 
COPY.  TYPK.  APPEND  and  so  on.  Other  DECnet  implementations  use  the 
Network  File  Transfer  (NFT)  utility.  Refer  to  your  programmer's  reference 
manual  to  determine  which  access  method  your  system  supports  for  terminal- 
based  file  access. 
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Regardless  of  which  method  is  implemented  on  your  system,  as  a  terminal 
user,  you  can  perform  the  following  file  operations: 

•  Transfer  (copy)  a  file  to  or  from  a  remote  node  or  between  two  remote  nodes. 

•  Delete  a  remote  file. 

•  Submit  a  local  command  file  for  execution  at  a  remote  node  or  execute  a 
command  file  already  existing  at  a  remote  node.  (Command  files  cannot  be 
submitted  to  or  executed  at  a  DECnet-RT  node.) 

•  Append  one  or  more  local  or  remote  files  to  an  existing  local  or  remote  file 
(on  DECnet-20  nodes,  supported  only  for  RJE-20  stations). 

•  Obtain  listings  of  remote  directories.  A  directory  file  lists  all  the  files  resid- 
ing on  a  device  that  belongs  to  a  specific  user  or  category. 

•  Queue  one  or  more  files  to  a  line  printer.  The  files  can  be  remote  and  the 
printer  local,  or  the  files  can  be  local  and  the  printer  remote  (on  DECnet-20 
nodes,  supported  only  for  RJE-20  stations). 

(Some  systems  supporting  system  commands  rather  than  NFT  also  enable 
you  to  create,  open,  and  close  remote  files  as  well  as  read  to  and  write  from 
them.  Check  system-specific  documentation  for  details.) 

On  behalf  of  the  terminal  user,  the  access  method  (be  it  NFT  or  system 
commands)  creates  a  logical  link  between  itself  and  the  remote  DECnet  soft- 
ware. From  the  input  a  user  types  at  the  terminal,  the  access  method  formu- 
lates the  appropriate  network  messages,  which  it  then  sends  over  the  link.  In 
turn,  the  target  program  interprets  the  messages  it  receives  and  interfaces 
with  its  local  file  system  as  requested.  The  target  program  then  returns  infor- 
mation and  any  requested  file  data  to  the  source  program  by  sending  back 
network  messages.  See  Section  9.4.2  for  examples  of  how  this  works  in  an 
applications  environment. 

6.2.1  Access  Control 

A  terminal  user  must  supply  the  same  access  control  information  that  a 
program  must  pass  to  perform  remote  file  access.  This  information  —  user 
identification,  password,  and  optional  account  data  —  must  be  available 
whenever  a  file  access  command  refers  to  a  remote  node.  Refer  to  system- 
specific  documentation  to  see  how  access  information  is  handled  in  terminal- 
based  file  access  on  each  system. 

6.2.2  File  Protection 

The  access  control  information  supplied  locally  by  the  terminal  user  deter- 
mines the  user's  access  rights  at  the  remote  node.  As  Section  6.1.4  describes, 
the  remote  file  system  compares  the  user's  identification  with  the  protection 
code  associated  with  the  file  to  be  accessed.  The  file  system  carries  out  a 
requested  access  only  if  the  protection  code  for  the  file  grants  access  to  the 
identified  user. 
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6.2.3   Remote  Pile  Specifications 

A  specification  that  describes  a  file  on  a  remote  node  must  conform  to  the 
remote  node's  syntax  rules.  If  the  remote  node  has  a  different  operating  sys- 
tem, the  remote  file  specification  may  contain  fields  or  conventions  that  the 
local  system  does  not  recognize. 

To  prevent  the  local  node  from  being  confused  by  a  foreign  syntax,  some 
implementations  require  the  user  to  enclose  the  foreign  specification  in  double 
quotes;  some  do  not.  Refer  to  the  programmer's  reference  manual  for  your 
system  for  specific  guidelines. 


6.2.4   Remote  Command  File  Submission 

Most  terminal-based  file  access  implementations  allow  a  terminal  user  to 
execute  a  command  file  in  a  remote  system.  A  command  file  contains  ASCII 
command  lines  equivalent  to  the  command  lines  a  user  enters  at  a  terminal. 
The  remote  node  reads  and  executes  these  commands  when  a  user  submits  the 
file.  See  system-specific  documentation  for  details  on  how  this  is  performed 
by  systems  that  support  the  option. 
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Chapter  7 

DECnet  Terminal  Facilities 


DECnet  implements  several  terminal  facilities  for  interactive  access  to  the 
network.  These  include: 

•  Interactive  terminal-to-terminal  communication 

•  Direct  access  to  a  remote  node's  operating  system  using  a  network  com- 
mand terminal  facility 

•  Remote  file  access  from  a  terminal 

This  chapter  presents  overviews  of  terminal-to-terminal  communication  and 
direct  access  to  a  remote  node's  operating  system.  Accessing  remote  files  from 
a  terminal  is  discussed  in  Chapter  6 

7.1    Interactive  Terminal-to-terminal  Communications 

Interactive  communication  between  two  DECnet  terminals  can  be  accom- 
plished in  several  ways: 

•  Phone.  The  VAXA^MS  operating  system  has  a  utility  called  Phone  that 
can  be  implemented  by  DECnet  to  allow  a  terminal-to-terminal  conversa- 
tion over  the  network  between  two  DECnet- VAX  terminal  users. 

Phone  allows  you,  as  a  terminal  user,  to  "dial"  another  terminal  user  on  the 
same  or  on  a  different  DECnet- VAX  node.  In  a  DIAL  command,  you  spec- 
ify the  name  of  the  target  node  and  the  name  of  the  person  you  want  to  talk 
to.  If  that  person  is  logged  on  and  available,  the  Phone  utility  notifies  them 
of  the  pending  phone  call  by  activating  the  bell  function  on  the  remote 
terminal  and  by  displaying  messages  on  that  person's  terminal  screen.  The 
person  you  are  calling  can  then  elect  to  answer  your  call  by  issuing  an 
ANSWER  command.  Once  your  call  is  answered,  the  two  of  you  can  type 
messages  interactively  from  your  terminals  in  the  manner  of  a  typed  conver- 
sation. At  the  end  of  the  conversation,  either  of  you  can  issue  a  command  to 
hang  up. 
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phone  has  a  number  of  options  that  can  be  used  to  provide  other  services 
and  information  to  terminal  users.  For  example,  there  is  a  directory  service 
listing  available  users  on  each  DECnet-VAX  system  supporting  Phone. 

NOTE 

DECnet  terminal  users  involved  in  communications  using 
the  VAXA'MS  Phone  utility  must  be  sure  that  the  node  they 
are  trying  to  communicate  v.ith  also  supports  it.  Nodes  sup- 
porting different,  although  similar,  utilities  cannot  communi- 
cate at  this  level. 


•  TLK.  Some  DECnet  systems  support  a  DECnet  utility  called  TLK.  TLK  is 
installed  as  part  of  DECn?t.  It  enables  terminal  users  on  two  DECnet-RSX 
systems  to  communicate.  Using  TLK,  you  can  send  single  messages  to 
another  terminal  user  (single  line  mode)  or  you  can  engage  in  an  interactive 
conversation  (dialog  mode).  To  send  a  message  in  either  mode,  you  issue  a 
TLK  command  specifying  a  node  name  and  terminal  identifier  for  the  ter- 
minal you  wish  to  "talk"  to.  The  user  at  the  other  terminal  receives  a  copy 
of  the  message(s)  sent,  along  with  the  identity  of  the  sending  terminal.  All 
messages  received  are  displayed  on  the  terminal  screen. 

Single  line  mode  messages  contain  just  one  line  and  are  terminated  when 
you  type  a  carriage  return  to  send  the  message.  To  end  a  "conversation"  of 
dialog  mode  messages,  either  user  can  type  a  (Dtrlz)  or  EXIT  command. 

You  can  also  use  TLK  to  send  messages  read  from  a  command  file.  TLK 
command  files  are  useful  for  sending  many  messages  at  once  and  for  storing 
and  sending  sets  of  messages  that  need  to  be  sent  more  than  once. 

TLK  is  not  supported  on  all  DECnet  systems.  Refer  to  user  documentation 
for  your  system  to  see  if  TLK  is  supported,  and  if  it  is,  for  details  on  how  to 
use  it.  Refer  to  Section  9.4.1  for  an  example  of  how  interactive  terminal 
communications  can  be  used  in  an  applications  environment. 

7.2    Network  Command  Terminal  Facilities 

All  DECnet  systems,  with  the  exception  of  DECnet-RT,  have  a  utility  that 
logically  connects  a  local  terminal  to  a  remote  node  operating  system  of  the 
same  type.  If  you  have  a  Phase  III  DECnet  system  that  supports  a  network 
command  terminal  facility,  you  can  communicate  with  other  DECnet  nodes 
of  the  same  type.  For  example,  a  DECnet-20  terminal  user  could  use  the 
SETHOST  terminal  facility  to  log  on  to  another  DECnet-20  node;  a  DEC- 
net/E  terminal  user  could  communicate  with  a  remote  DECnet/E  node  using 
the  utility  called  Network  Command  Terminal  (NET).  (Intermediate  routing 
nodes  can  be  any  DECnet  implementation.)  Refer  to  system-specitlc  docu- 
mentation for  details  on  how  to  use  available  network  command  terminal 
utilities. 
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Although  different  DECnet  systems  can  support  different  network  command 
terminal  utilities,  each  one  allows  a  terminal  user  issuing  appropriate  com- 
mands to  temporarily  become  a  "local"  user  of  a  specific  remote  node.  The 
network  command  terminal  utility  or  command  in  the  source  node  sets  up  a 
logical  link  with  a  cooperating  program  in  the  remote  node.  The  resulting 
connection  allows  the  user  to  perform  most  functions  that  the  remote  node 
allows  its  local  users  to  perform  (see  Figure  7-1  for  an  example). 
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Figure  7-1:    Remote  Terminal  Processing 

The  ability  to  set  up  a  logical  connection  between  a  terminal  and  a  remote 
node  has  numerous  applications.  Remote,  interactive  program  development  is 
possibly  the  most  common  and  important  application.  If  the  local  node  does 
not  havc  the  resources  necessary  to  support  program  development  (a  DEC- 
net-US  node,  for  example,  has  no  mass  storage  facilities),  a  programmer  can 
obtain  access  to  a  remote  node  that  has  the  required  resources. 

Phase  IV  DECnet  provides  an  enhanced  network  command  terminal  function 
referred  t'>  as  the  network  virtual  terminal  (NVT)  service.  As  in  Phase  III 
DECnet.  NVT  terminal  users  can  connect  to  nodes  having  the  same  kind  of 
DECnet  system.  However,  NVT  provides  the  enhanced  capability  of  allowing 
Phase  IV  DECnet  terminal  users,  either  on  a  DECnet  node  or  on  a  terminal 
server,  to  connect  to  other  Phase  IV  nodes  of  different  types  that  support 
NVT.  Refer  to  documentation  for  your  system  to  ascertain  whether  or  not  it 
supports  NVT  capabilities. 
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Chapter  8 

Internetwork  Communications 


DEC'net  enables  you  to  perform  internetwork  communications  —  communica- 
tions with  a  network  other  than  DECnet.  Specifically,  you  can  communicate 
with  DEC'net  and  non-DEC'net  systems  over  an  X.'io  packet -switching  data 
network  (FSDN)  and  with  systems  in  an  IBM  SNA  network. 

In  order  to  communicate  with  DEC^net  or  non-DECnet  systems  over  a  PSDX 
using  X.25  communications,  you  ne^-d  either  a  DEC'net  system  with  Packet - 
net  System  Interface  (PSI)  software  .nstalled  or  a  DEC'net  system  that  has  an 
X.2.VX.29  extension  package  (XEP)  installed  and  can  be  connected  by  DEC- 
net to  a  R()uter/X.25  Oateway  (see  Section  8  1.:^). 

To  communicate  with  an  IBM  mainframe  in  an  SNA  environment,  you  need  a 
DECnet/SNA  Gateway  node  and  DECnet/SNA  software  subroutines  installed 
in  your  DECnet  node  (see  Secimn  8.2;. 

This  chapter  describes  briefly  what  these  additional  software  components  are 
and  how  you  use  them  in  internetwork  com*  Mnications.  For  further  details, 
refer  to  system-specific  documentation. 
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• 


x.25  is  a  recommendation  of  the  Comite  Consultatif  International  Telepho- 
nique  et  Telegraphique  (CCITT)  which  defines  a  standard  means  for  comput- 
ers to  interface  with  packet-switching  data  networks.  A  packet-switching  data 
network  (FSDN)  is  a  data  communications  service  offered  by  common  carri- 
ers, such  as  the  Postal  Telephcme  and  Telegraph  Authorities  (PIT).  Packet- 
switching  data  networks  are  widespread,  with  the  number  increasing  every 
year.  They  are  a  viable  means  of  sharing  telecommunications  costs  and  ser- 
vices with  u.sers  outside  of  your  own  network. 

NOTE 

While  all  public  packet-switching  data  networks  must  use  the 
X.2n  interface,  private  carriers  can  al.so  run  a  packet -switching 
network  service  using  X.25  standards. 
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As  the  name  indicates,  a  packet -switihing  data  network  is  one  that  receives 
addressed  packets  ot  data  from  network  users  and  conveys  them  through 
internal  switching  routines  to  specitied  receivers.  The  way  the  network  de- 
livers the  packets  is  completely  transparent  to  the  end  user  who  has  no  intlu- 
ence  over  the  path  the  packet  takes  through  the  network.  The  way  that  the 
data  packets  get  from  the  user  to  the  PSDN  is  what  the  X.'io  recommendation 
outlines. 

The  X.'i')  recommendation  defines  standards  that  govern  the  relationship 
between  users  and  the  I\SI)N  network  on  the  tbllowing  levels: 

•  Level  1,  the  physica!  level.  Defines  the  mechanical,  electrical,  functional, 
and  procedural  characteristics  of  the  physical  link  between  the  network 
user's  ec^uipment  and  the  PSDN  network  ec^uipment 

•  Level  2,  the  frame  level.  Defines  the  link  access  procedure  for  a  data 
exchange  over  the  communications  link  between  the  user  and  the  PSDN 

•  Level  3,  the  packet  level.  Defines  ne  packet  format  and  procedures  lor 
the  exchange  ot  packets  containing  control  information  and  user  data  be- 
tween the  user  and  the  FSDN 

Following  the  X.25  recommendation,  a  header  containing  control  and  destina- 
tion information  is  included  as  part  of  each  data  packet  submitted  to  the 
FSDN  network.  (In  DKCnet  implementations.  X.25  software  described  in 
Section  8.1.:^  creates  this  header.)  The  header  information  tells  the  PSDN 
who  is  sending  the  data  and  who  is  to  receive  it.  That  way.  no  matter  what 
kind  of  system  or  language  is  used  to  generate  the  data  message,  the  I\SDN 
can  recognize  the  header  information  and  route  the  packet  to  its  proper  desti- 
nation. 

The  F^SDN  shares  its  transmission  lines  by  interleaving  packets  from  many 
senders.  This  provides  fast  and  economical  service.  The  network  differentiates 
between  multiple  packets  on  a  line  by  means  of  a  numbering  scheme  that 
assures  the  packets  get  sent  to  the  proper  destination  in  the  correct  order. 

8.1.1    DTEsandDCEs 

Each  PSDN  consists  of  a  number  of  geographically  separated  switching  nodes 
that  are  connected  by  high  speed  links.  When  you  lease  a  circuit  from  the 
PTT  or  other  carrier,  the  circuit  connects  your  computer  to  one  of  the  PSDN 
switching  nodes.  The  PSDN  switching  nodes  are  called  network  interfaces  or 
data-circuit-terminating  equipment  (DC'E).  I'ser  computers  or  terminals  con- 
nected to  DCEs  are  called  data  terminal  equipment  (DTE).  Figure  8-1  illus- 
trates these  components. 


I* 


e 


8-2       Introduction  to  DECnet 


• 


LEGEND: 
DCE 


A  LEASED  CIRCUIT  OR 
DIAL-UP  LINE 


Data  circuit-terminating  equipment, 
a  PSDN  switching  node 


DTE  Data  terminal  equipment,  a  user 

computer  or  a  terminal  using  the  PSDN 

Figure  8-1 :    Components  of  a  Packet-switching  Data  Networic 


8.1.2    X.25  Circuits 

Two  DTEs  (for  example,  your  system  and  the  one  you  want  to  communicate 
with  over  the  PSDN)  communicate  by  means  of  one  or  more  virtual  circuits.  A 
virtual  circuit  is  a  logical  association  set  up  by  the  PSDN  either  permanently 
or  temporarily.  Each  virtual  circuit  handles  the  exchange  of  data  between  two 
specific  DTEs.  The  DTE  at  each  end  assigns  a  logical  channel  and  a  corre- 
sponding channel  number  to  the  circuit.  When  sending  data,  the  DTE  in- 
cludes a  logical  channel  number  to  identify  the  channel  and  the  corresponding 
circuit  to  which  the  data  belongs. 
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Wlien  a  DTE  uses  more  than  one  virtual  circuit  at  a  time  (that  is,  multiple 
circuits  to  the  same  destination  or  circuits  to  several  dilterent  destinations), 
the  circuits  are  multiplexed  over  the  physical  link  hetween  the  DTK  and  the 
DCE.  Virtual  circuits  are  either  permanent  or  temporary  (switched): 

•  Permanent  virtual  circuits.  A  permanent  virtual  circuit  (PVC)  is  analo- 
gous to  a  leased  line  hetween  a  local  and  a  remote  DTE.  F^ither  DTK  can 
send  data  over  the  P\'C  at  any  time  without  issuing  calls  to  set  up  or  hreak 
the  circuit.  When  a  user  suhscrihes  to  a  PSDN,  the  administraton-.  ol"  the 
FSDN  allocate  the  logical  channel  numher  for  each  PVC  to  he  used. 

•  Switched  virtual  circuits.  A  temporary  association  between  two  DTEs  is 
called  a  switched  virtual  circuit  (S\T).  A  DTE  sets  up  this  type  of  circuit 
only  when  it  wants  to  send  data.  The  sending  DTE  assigns  a  channel, 
identifies  the  target  DTE.  and  then  obtains  that  DTE's  agreement  to  com- 
municate. When  the  DTEs  have  finished  exchanging  data,  one  or  the  other 
initiate.:,  a  clearing  sequence  to  terminate  the  SVC. 

If  you  are  using  an  X.25  native  mode  user  interface  as  discussed  in  Section 
8.1.3,  you  must  issue  calls  in  an  application  program  to  specify  or  create  a 
virtual  circuit  with  a  remote  DTE.  If  you  use  data  link  mapping  (DLM)  mode 
as  discussed  in  Section  8.1.3,  you  simply  include  the  node  and  task  name  of 
the  destination  DTE  and  the  DECn^t  routing  mechanism  handles  the  selec- 
tion ot  circuits  as  it  would  over  any  DECnet-to-DECnet  connection.  (I'sing 
DLM,  the  user  is  not  even  aware  that  the  connection  with  the  destination 
node  is  occurring  over  a  PSDN.) 

8.1.3   X.25  Access  Methods 

Access  methods  refer  to  how  you  establish  communications  over  a  PSDN.  As 
mentioned  previously,  you  need  specific  software  and,  in  some  cases,  hard- 
ware products  in  your  network  for  X.25  communications.  What  you  need 
depends  on  with  whom  you  want  to  communicate.  You  can  access  a  PSDN  to 
communicate  with  other  DECnet  systems  or  with  non-DECnet  systems. 

If  you  communicate  only  with  DECnet  systems,  you  may  be  able  to  use  a 
DECnet  facility  called  data  link  mapping  (DLM).  (Check  system-specific 
documentation  to  see  if  your  system  supports  DLM.  Some  systems,  such  as 
DECnet-10  and  DECnet-20  do  not.) 

DLM  allows  two  DECnet  nodes  to  communicate  as  though  the  PSDN  were 
not  even  there.  In  fact,  the  X.25  interface  is  completely  transparent  to  both 
users.  To  use  DLM,  you  must  be  able  to  send  your  data  through  a  DECnet 
node  that  has  PSI  software  installed.  This  node  must  be  positioned  as  a  DTE 
in  relation  to  the  PSDN.  If  you  do  not  have  access  to  such  B  n^de,  you  can 
send  the  data  through  a  DECnet  Router/X.25  Gateway  node  on  an  Ethernet. 
Using  the  DLM  interface,  your  node  can  be  located  anywhere  on  the  network 
and  does  not  require  any  special  software  other  than  DECnet. 
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If  you  want  the  option  of  talking  to  DECnet  or  non-DECnet  systems  over  the 
PSDN,  you  need  different  software.  RSX-11,  VAX/VMS,  and  TOPS-20  oper- 
ating systems  have  PSI  software  that  you  can  install  into  your  corresponding 
DECnet  system.  This  software  allows  you  to  communicate  in  X.25  native 
mode  if  you  are  directly  connected  to  a  PSDN.  (TOPS-20  software  is  divided 
into  two  categories:  [1]  PSI  gateway  software  installed  in  the  DN2()  front-end 
processor,  which  provides  gateway  functions  [2]  PSI  access  routines  installed 
in  the  DECsystem-:^()  main  processor.  The  access  routines  communicate  with 
the  gateway  software  to  set  up  a  connection  with  the  PSDN.  Because  the 
DN2()  is  the  DTE  in  these  connections,  it  must  be  directly  connected  to  the 
PSDN.) 

X.25  native  mode  essentially  provides  the  complete  X.25  programming  inter- 
face, which  can  be  interpreted  by  any  system  on  a  PSDN  regardless  of  vendor. 
As  long  as  the  remote  DTE  uses  the  X.25  protocol,  which  it  must  as  a  require- 
ment of  the  PSDN.  then  you  can  communicate  with  it. 

I'sing  PSI  software  in  native  mode  enables  you  to  write  application  programs 
to  access  resources  on  the  other  DTE.  This  involves  issuing  calls  to  create  or 
specify  virtual  circuits,  send  and  receive  data,  and  terminate  communica- 
tions. Refer  to  PSI  documentation  for  specific  operating  systems  for  a  list  of 
supported  calls,  functions,  and  languages  you  can  use. 

PSI  .software  in  DECnet-VAX  nodes  and  DECnet-RSX  nodes  also  provides 
the  DLM  interface  for  communication  with  DECnet  systems  over  the  PSDN. 
DECnet  nodes  containing  PSI  software  do  not  require  the  services  of  interven- 
ing DTEs  or  DECnet  Router/X.25  Gateway  nodes. 

If  you  are  using  a  DECnet-VAX  node  and  do  not  want  to  install  PSI  .software, 
you  can  install  a  VAX-11  X.25/X.29  Extension  Package  (XEP)  into  your 
node.  The  extension  package  pn^viJes  subroutines  that  enable  you  to  use 
DECnet  communication  facilitlf:^  to  create  and  transmit  data  packets  con- 
taining X.25  information.  The  XEP  data  packets  that  you  send  are  received 
by  corresponding  X.25  software  in  a  DECnet  Router/X.25  Gateway;  you  can- 
not use  the  XEP  without  the  services  of  the  Gateway.  (The  combination  of 
XEP  software  and  the  gateway  facilities  provides  you  with  the  complete  X.25 
native  mode  programming  interface.)  The  DECnet  Router/X.25  Gateway  is 
directly  connected  to  the  PSDN  and  translates  the  XEP  messages  it  receives 
into  X.25  native  mode  that  allows  you  to  communicate  with  DECnet  and  non- 
DECnet  svstems  over  the  PSDN. 


NOTE 

Multiple  DECnet  nodes  can  share  a  single  X.25  connection  to  a 
PSDN  through  the  gateway  or  by  using  DLM. 
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8.1.4    CCITT  Recommendations  X.3,  X.28,  and  X.29 

Thus  far,  discussion  in  this  chapter  has  involved  computers  or  terminals  that 
send  "packets"  of  data  to  the  PSDN.  These  systems  are  referred  to  as  packet 
mode  DTEs.  There  are,  however,  nonpacket  mode  systems,  such  as  asynchro- 
nous terminals.  These  systems  can  also  communicate  as  DTHs  over  a  PSDN. 
CCITT  has  defined  three  recommendations  describing  the  PSD\  interface  for 
nonpacket  mode:  X.3,  X.28,  X.29. 

•  X.3.  Describes  the  basic  functions  and  user-selectable  facilities  of  the 
packet  assembly/disassembly  facility  (PAD)  for  terminals  operatin}^  in  non- 
packet  mode  in  a  public  data  network. 

•  X.28.  Specifies  how  to  control  the  user-selectable  functions  of  the  PAD  from 
the  terminal. 

•  X.29.  Specifies  procedures  for  the  exchange  of  control  information  and  user 
data  between  a  packet  mode  DTE  and  a  packet  assembly/disassembly 
(PAD)  facility. 

A  PAD  is  a  facility  provided  by  the  PSDN.  It  acts  as  an  interface  between  the 
nonpacket  mode  DTE  and  the  network  DCE.  The  terminal  user  connects  to 
the  PAD  and  commands  it  to  establish  a  virtual  circuit  to  a  destination  DTE. 
The  PAD  receives  the  character-by-character  data  generated  by  the  user  ter- 
minal, re-forms  it  into  packets,  and  dispatches  the  packets  through  the  net- 
work to  the  remote  computer.  At  the  remote  computer,  a  pseudodevice  called 
the  X.29  Virtual  Terminal  Driver  handles  information  sent  by  the  terminal 
user  in  much  the  same  way  as  a  regular  DECnet  terminal  device  would.  That 
is,  it  sets  terminal  characteristics  specified  by  the  remote  terminal,  such  as 
type-ahead  options  and  line  terminators  and  delivers  the  information  to  the 
appropriate  application  on  the  remote  computer.  The  PAD  and  the  X.29 
Virtual  Terminal  Driver  operate  in  a  manner  that  is  transparent  to  the  user. 
The  terminal  appears  to  the  terminal  user  as  though  it  were  directly  con- 
nected to  the  remote  computer. 

I'sing  this  same  PAD  principle,  asynchronous  terminals  connected  to  a  DEC- 
net-VAX  node  with  VAX-U  PSl"or  VAX-11  X.25/X.29  XEP  installed  can 
initiate  a  circuit  with  another  DECnet  or  non-DECnet  system  over  the  PSDN 
without  buying  the  services  of  the  PSDN  PAD  facility  VAX-II  PSI  and 
\^AX-11  X.25/X.29  XEP  each  contain  a  program  that  emulates  the  functions 
<^f  a  PAD  on  the  DECnet  system.  (The  standard  DECnet  terminal  interface  is 
used  in  these  communications.) 

In  addition  to  the  cost  savings  entailed  in  having  a  built-in  "PAD"  as  opposed 
to  leasing  the  option  from  a  PSDN.  VAX-11  PSI  and  VAXll  X.25/X.29 
XEP  software  enable  a  DECnet-VAX  node  to  initiate  and  to  respond  to 
nonpacket  mode  communications.  Without  the  VAX-11  PAD  function,  an 
asynchronous  terminal  connected  to  a  DECnet-VAX  node  can  only  respond  to 
messages  initiated  by  terminals  c(mnected  to  the  PSDN  PAD. 

The  relationships  that  occur  between  X.3,  X.28,  X.29,  and  the  PSDN  are 
shown  in  Figure  8-2. 
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Figure  8-2:    Relationships  between  X.3,  X.28,  X.29  and  the  PSDN 


The  X.3,  X.28,  and  X.29  recommendations  are  layered  on  top  of  X.25.  That 
is,  they  provide  standards  for  nonpacket  mode  systems  to  communicate  over  a 
PSDN  that  are  required  in  addition  to  the  protocols  defined  by  X.25.  Digital 
PSI  products  include  provisions  for  X.25,  X.3,  X.28,  and  X.29  recommenda- 
tions. Therefore,  information  in  this  chapter  describing  X.25  communica- 
tions, including  access  methods,  also  applies  to  these  other  standards. 


8.2    DECnet/SNA  Communications 

DECnet/SNA  communications  involve  sending  data  from  one  or  more  DEC- 
net-VAX  or  DECnet-RSX  nodes  through  a  Gateway  to  an  IBM  system  in  an 
SNA  network.  The  protocol  differences  between  the  IBM  network  and  the 
Digital  network  are  resolved  by  interceding  functions  in  the  Gateway.  The 
Gateway  is  seen  by  IBM  as  a  PU  (Physical  Unit)  Type  2  cluster  controller. 

NOTE 

Tht  term  Gateway  is  used  in  this  discussion  to  refer  to  all 
implementations  of  the  DECnet/SNA  Gateway  node. 
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The  functions  performed  at  the  Gateway  are  not  visible  to  the  end  user.  As  .ar 
as  the  user  is  concerned,  the  (Gateway  is  a  bhuk  box  that  manages  to  receive 
DKCnet  data  on  one  side  and  send  out  SNA  data  on  the  other.  The  DEC^net 
node(s)  and  the  Gateway  involved  in  these  communications  can  be  located 
either  in  a  wide  area  network  or  on  the  Ethernet  as  shown  in  Figure  8-.'^ 
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Figure  8-3:    DECnet/SNA  Environments 


The  major  criteria  for  participation  in  DECnet/SNA  communications  is  that 
you  have  a  DECnet-VAX  or  DECnet-RSX  node  with  appropriate  DEC- 
net/SNA software  installed  and  access  to  a  Gateway.  (Operating  requirements 
for  the  IBM  system  to  communicate  with  the  (Jateway.  such  as  supported 
subsystems  and  component  parameters  are  detailed  in  the  DECnet/SNA 
Gateway  Installation  CJuide.) 


8-8       Introduction  to  DECnet 


The  software  required  on  the  (lateway  is  specific  and  unchangeable  as  de- 
scribed in  the  DKCnet/SNA  documentation.  You  do  have  some  options,  how- 
ever, as  to  the  DECnet/SNA  software  packages  you  install  on  your  DKC^net 
system.  The  packages  you  install  will  depend  on  which  functions  you  want  to 
implement.  DKCnet/SNA  software  is  available  to  perform  each  of  the  follow- 
ing activities: 

•  Write  application  programs  thai  communicate  with  programs  in  an  IBM 
network  (DPX'net/SNA  Application  Interlace  software) 

•  Access  IBM  applications  using  a  Digital  terminal  as  though  it  were  an  IBM 
3270  Informaticm  Display  System  (IDS)  terminal  (DKCnet/SNA  M27()  Ter- 
minal Kmulator  software) 

•  Submit  jobs  to  an  IBM  system  and  receive  job  output  for  them  (DPX'- 
net/SNA  Remote  -Job  Pantry  (HJE)  software) 

There  are  also  management  tools  that  er-'.ble  you  to  manage  and  maintain 
(iateway  operations. 

8.2.1    DECnet/SNA  Circuits 

Communications  between  a  DKCnet  node  and  the  (lateway  node  occur  over 
DDCMP  or  Ethernet  circuits  (see  Section  2.2).  Communications  between  the 
(iateway  node  and  the  IBM  system  occur  over  SDLC  circuits.  To  perform 
certain  DECnet/SNA  functions,  you  may  have  to  identify  particular  circuits. 
Circuit  IDs  are  specified  differently  for  DDCMF  and  SDL(^  circuits.  Informa- 
tion on  specifying  circuit  IDs  of  each  type  of  circuit  is  contained  in  the  DEC- 
net/SNA (lateway  management  guide  for  your  system. 

It  is  also  important  to  note  that  soine  system  management  activities  related  to 
SDLC  lines  and  circuits  require  you  to  set  the  Cateway  node  as  the  command 
executor,  inform.ation  on  how  to  do  this  is  also  contained  in  the  DF^Cnet/SNA 
management  guide  for  your  system. 


8.3    Loading  the  Gateway  Node  Software 

As  Figure  8-8  shows,  there  are  two  implementations  of  the  Gateway  node:  one 
resides  on  an  Ethernet  cable,  the  other  does  not.  Functionally,  both  nodes  are 
the  same.  However,  if  the  (iateway  is  attached  to  an  F^thernet  cable,  it  must 
be  down-line  loaded  from  a  DECnet-\'AX  or  a  DFXnet  RSX  host  node  also 
on  the  Ethernet.  If  the  (iateway  node  is  not  located  on  the  Ethernet,  it  can  be 
loaded  directly  from  floppy  disks  and  bootstrapped  either  manually  or  by 
means  of  a  TRKiCiER  command  from  a  host  node. 
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Chapter  9 

How  DECnet  Supports  Applications 


This  chapter  describes  how  the  DECnet  capabilities  discussed  in  the  preced- 
ing chapters  support  applications  running  in  a  user  environment. 

For  illustrative  purposes,  the  user  environment  posed  here  consists  of  several 
interacting  application  subsystems  that  support  the  daily  operations  of  a 
fictional  company  called  Fictional  Corporation.  The  subsystems  and  applica- 
tions used  in  this  example  are: 

Marketing  Subsystem 

•  Order  Entry 

•  Sales  Analysis 

•  Market  Research 

Manufacturing  Subsystem 

•  Production  Scheduling 
•Inventory 

•  Quality  Control 

•  Purchasing 

Accounting/Financial  Subsystems 

•  Billing 

•  Accounts  Receivable 

•  Short-term  Cash  Management 

Figure  9-1  illustrates  the  interaction  among  these  subsystems  and  applica- 
tions only  insofar  as  the  following  discussion  is  concerned.  The  financial  sub- 
system and  the  short-term  cash  management  application,  for  example,  in- 
teract with  other  subsystems  and  applications  not  shown  here. 
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Figure  9-1:    Subsystem  and  Application  Interaction  at  Fictional 
Corporation 

The  order  entry  application  captures  a  basic  set  of  information,  including 
customer  name,  address,  products  ordered,  and  delivery  requirements.  If 
products  ordered  come  out  of  finished  goods  inventory,  the  basic  set  of  infor- 
mation is  then  input  to  order  assembly  and  dispatch  applications;  if  the 
ordered  goods  are  to  be  produced,  as  is  the  case  in  the  example  to  be  pre- 
sented, the  information  goes  to  a  production  scheduling  application,  which 
then  interacts  with  raw  materials  inventory  and/or  component  inventory.  If 
required,  the  inventory  applications  interact  with  purchasing.  The  production 
scheduling  system  updates  a  corporate  data  base  that  records  historical  and 
scheduled  utilization  of  production  facilities. 

The  billing  and  delivery  scheduling  applications,  not  shown  here,  also  use  the 
basic  information  set,  along  with  other  information  retrieved  from  various 
data  bases  accessed  and  updated  by  the  complex  of  application  systems. 
Accounts  receivable,  which  interacts  with  credit  and  billing  applications,  is 
updated  on  a  regularly  scheduled  basis. 
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Since  Fictional  is  an  international  company,  it8  application  programs  must 
interact  both  within  and  over  national  boundaries.  The  nodes  in  Fictitmal's 
DECnet  network  communicate  over  national  packet-switching  networks  in 
the  United  Kingdom,  the  United  States,  Canada,  France,  the  Netherlands, 
and  West  Germany.  These  cost-effective  communications  facilities  imple- 
ment the  X.25  recommendation  of  the  CCIIT.  Requirements  for  communi- 
cating over  such  PSDNs  within  and  over  national  boundaries  are  met  at 
Fictional  by  means  of  the  DECnet  Router/X.25  gateway  nodes  and  X.25  Pack- 
etnet  System  Interface  (PSI)  capabilities  resident  in  general  purpose  DECnet 
nodes  (see  Chapter  8). 

Company  structure  dictates  a  need  for  combined  wide  area  and  local  area 
networks.  The  processors,  terminals,  and  personal  computers  connected  to  the 
network  are  at  functionally  defined  locations,  such  as  sales  offices,  manufac- 
turing facilities,  warehouses,  distribution  centers,  and  corporate  headquar- 
ters. DECnet  nodes  at  these  locations  are  linked  to  one  another  by  leased  lines 
and  X.25  networks.  In  addition,  some  applications  require  interaction  be- 
tween DECnet  nodes  and  IBM/SNA  systems. 

The  following  sections  illustrate  how  DECnet  capabilities  support  Fictional's 
applications.  DECnet  capabilities  discussed  in  this  context  i   elude: 

•  Task-to-task  communication 

•  File  Transfer 

•  Remote  File  Access 

•  Terminal  Communications 


9.1    DECnet's  Task-to-task  Capability  in  an  Application 
Environment 

DECnet's  task-to-task  capability  handles  all  the  network  processing  that  en- 
ables Fictional's  application  systems  to  interact  with  one  another  over  the 
network.  As  noted  in  Chapter  5,  this  same  capability  also  enables  application 
programs  to  interact  with  DECnet  modules  and  DECnet  modules  to  interact 
with  one  another.  In  this  example,  only  the  program-to-program  interaction  is 
discussed. 

The  only  requirement  that  network  communication  imposes  on  Fictional's 
programmers  is  that  the  applications  issue  calls  to  network  services  and  that 
they  be  written  to  cooperate  with  one  another  insofar  as  data  formats  and 
function-specific  data  transfer  operations  are  concerned.  Logical  link  process- 
ing by  DECnet  is  completely  transparent  to  terminal  operators. 
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The  logical  links  (see  Chapter  4)  over  which  the  numerous  applications  com- 
municate are  set  up  automatically  by  the  DECnet  software.  Because  it  is 
designed  in  accordance  with  the  specifications  of  the  Digital  Network  Archi- 
tecture, the  DECnet  software  offers  a  standard  application-network  interface. 
All  of  Fictional's  applications,  no  matter  in  what  DECnet  nodes  they  run, 
access  the  network  by  means  of  the  same  mechanism.  This  common  approach 
to  the  network  interface  encourages  open-ended  design  of  application  systems. 
This,  in  turn,  assures  that  future  applications  developed  by  Fictional's  pro- 
grammers will  be  compatible  with  the  existing  set  at  the  networking  level. 

9.1.1  Order  Entry  and  Production  Scheduling 

As  an  example  of  how  DECnet  task-to-task  capabilities  operate,  the  following 
discussion  outlines  the  environment  in  which  logical  links  are  set  up,  con- 
trolled, and  terminated  as  the  order  entry  and  production  scheduling  applica- 
tions interact. 

The  order  entry  application  runs  in  local  sales  offices.  Figure  9-2,  which 
isolates  one  area  of  the  corporate  network,  illustrates  three  levels  of  communi- 
cation: 

•  Betv^een  local  and  regional  sales  offices  {order  entry  application  and  sales 
analysis  application) 

•  Between  regional  sales  offices  and  corporate  headquarters  (sales  analysis 
application  and  market  research  application) 

•  Between  local  sales  offices  and  corporate  headquarters  (order  entry  applica- 
tion and  production  scheduling  application) 

Basic  information  captured  at  the  local  level  consists  of  customer  name,  bill- 
ing and  delivery  addresses,  products  ordered,  and  delivery  requirements. 

The  production  scheduling  application  is  centralized  at  corporate  headquar- 
ters. This  application  system  matches  order  requirements  against  available 
production  facilities  (as  recorded  on  the  production  scheduling  data  base)  and 
against  raw  materials  and  component  inventory.  It  then  posts  an  indication 
back  to  the  order  entering  f^ales  office  as  to  whether  or  not  delivery  require- 
ments can  be  met.  If  they  can  be  met,  the  production  scheduling  system 
notifies  the  appropriate  manufacturing  locations  and  updates  the  production 
scheduling  data  base. 

9.1.2  Networlc/AppllcatJion  Interaction 

Logical  link  processing  between  the  applications  covers  three  distinct  opera- 
tions: 

•  Establishment  of  the  link 

•  Control  of  the  link 

•  Destruction  of  the  link 

Each  is  discussed  in  the  following. 
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j^     LOCAL  SALES  OFFICE 


(^     LOCAL/REGIONAL  SALES  OFFICE 
^    CORPORATE  HEADQUARTERS 


Figure  9-2:    Three  Applications  Linked  by  DECnet's  Tasl(-to-tasl( 
Capability 


Establishment  of  the  Linlc 

Data  entry  operators  working  with  VTIOO  terminals  at  the  sales  offices  invoke 
the  order  entry-  transaction  system  and  complete  order  entry  forms  displayed 
on  the  terminal  screens.  From  the  operator's  viewpoint,  the  procedure  is 
straightforward.  Order  information  is  entered  on  the  forms;  the  completed 
forms  are  ENTERED;  a  new  form  appears.  Transmission  is  transparent.  On 
an  applications  level,  the  entered  orders  are  checked  locally  against  customer 
and  product  files.  Any  errors  are  indicated  back  to  the  operator  for  correction. 

On  a  network  level,  similarly  transparent  to  the  operator,  the  order  entry 
system  opens  communication  with  DECnet.  Then,  by  issuing  connect  re- 
quests, it  tries  to  establish  logical  links  with  a  sales  analysis  system  at  the 
regional  sales  office  and  with  the  production  scheduling  system  at  corporate 
headquarters. 
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If  the  other  applications  are  ready  to  communicate  with  order  entry,  the 
programs  are  logically  linked,  and  they  begin  exchanging  data  in  accordance 
with  the  rules  established  by  the  cooperating  applications. 

Both  the  production  scheduling  and  sales  analysis  systems  could  be  receiving 
order  entry  information  simultaneously  from  other  terminals  at  the  =aiViC  Bnd 
at  other  sales  offices.  DECnet  sets  up  unique  logical  links  for  each  pair  of 
applications  bound  in  a  session.  Any  communications  from  production  sched- 
uling back  to  order  entry  during  the  same  se.ssion.  such  as  notification  that  the 
delivery  requirements  specified  cannot  be  met.  are  transmitted  over  the  logi- 
cal link  initially  established  between  the  two  programs  at  the  beginning  of  the 
session. 

Control  of  the  Link 

In  the  course  of  the  sessions  between  the  programs,  DECnet  monitors  and 
controls  the  links,  making  sure  that  all  transmitted  data  is  received  and  that 
all  data  received  at  the  data  link  level  is  turned  over  to  the  receiving  program 
in  proper  sequence. 

Order  data  records  are  of  variable  length.  DECnet  at  the  sending  node  seg- 
ments the  record  and  specifies  a  sequence  number  for  each  segment.  DECnet 
at  the  receiving  node  acknowledges  receipt  of  each  segment  by  sequence  num- 
ber and  assembles  message  segments  in  the  order  specified  by  the  sequence 
numbers. 

To  make  certain  that  the  order  entry  and  production  scheduling  applications 
interact  efficiently.  DECnet  requires  that  the  receiving  program  issue  RE- 
CEIVE calls  that  set  up  buffers  for  the  receipt  of  data.  DECnet  at  the  sending 
node  will  not  transmit  data  unless  it  is  notified  that  a  buffer  is  available  at  the 
destination  node  for  the  receipt  of  message  segments.  DECnet  employs  this 
flow  control  technique  to  make  sure  that  buffer  overflow  conditions  do  not 
arise.  Conditions,  therefuie,  iliai  cause  messages  to  be  retransmitted,  thus 
increasing  communications  overhead,  are  not  permitted  to  arise. 

Destruction  of  the  Link 

When  all  order  data  has  been  er^ered.  DISCONNECT  and  CLOSE  calls  are 
made  to  the  network.  The  logic  link  binding  the  programs  is  destroyed,  and 
the  network  resources  that  were  employed  in  maintaining  that  link  are  re- 
leased. 


• 


9.2    DECnet's  File  Transfer  Capability  in  an  Application 
Environment 

At  Fictional  Corp..  file  transfer  operations  over  DECnet  are  initiated  by  ter- 
minal operators  and  by  programs.  Examples  of  each  are  presented  in  the 
following  subsections. 
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9.2.1    Market  Research  and  Sales  Analysis 

Fictional's  market  research  system  runs  at  corporate  headquarters.  It  takes 
input  trom  the  sales  analysis  applications  running  at  the  regional  sales  offices 
and  from  market  research  analysts  located  worldwide  (see  Figure  9-;^). 

Input  from  sales  analysis  provides  historical  information  that  is  used  to  plot 
|)roducl  acceptance  trends.  Input  from  market  research  analysts  quantifies 
market  trends  in  specific  geographical  areas  and  projects  the  impact  (jf  new 
prof'  .cts  on  existing  and  forecasted  customer  bases. 

Market  research  analysis  is  supported  by  a  series  of  charts  produced  by  the 
sales  analysis  application.  These  charts  are  written  to  tiles  that  are  then  made 
available  to  the  research  analysts.  'I'erminal  operators  at  the  regional  sales 
offices  use  electronic  mail  over  DKCnet  to  notify  the  analysts  when  a  new  set 
of  charts  is  available. 

The  analyst.^  edit  these  charts,  supplying  aflditional  input  and  modifying 
existing  data.  Some  use  DKCnet  file  transfer  capa})ilities  to  transfer  the  chart 
files  from  the  market  research  application  at  corporate  headquarters  to  their 
local  nodes;  others  use  the  same  DIX'iR-t  facility  to  copy  them  to  accounts 
thai  they  have  on  the  node  running  the  market  research  system  at  corporate 
headquarters.  Some  prefer  to  print  the  files  and  work  on  the  hard  copies  of  the 
charts:  others  use  the  editing  feature  available  at  their  local  nodes  to  update 
the  charts  on-line. 

Analysts  working  at  DKCnet  \'AX  nodes,  inr  example,  use  the  COPY  com- 
mand, as  follow>.  to  obtain  the  chart  files.  Note  that  in  this  and  in  subsequent 
exami)les.  user  input  is  printed  in  red  and  system  output  is  printed  in  black. 

<    COPY    CUA;;:  rCHAfyT.CUR    ♦.* 

In  the  above  example,  the  research  analyst  copys  a  file  called  CHART. CTR 
that  resides  on  node  (A'AX.  This  command  line  shown  here  causes 
CHART. (T'R  on  node  C\'AX  to  be  written  to  a  file  of  the  same  name  on  the 
local  n:)de.  A  different  file  name  can  be  specified. 

As  shown  in  Figure  9-4.  the  COPY  request  (solid  line)  and  response  (dotted 
line)  may  be  routed  through  multiple  nodes.  To  the  requester,  however,  this 
network  activity  is  transparent.  The  preferred  path  for  each  transmission  is 
selected  by  the  DECnet  routing  capability. 

The  DKCnet-A'AX  node  at  corporate  headquarters  runs  ALL-IN- 1  software, 
an  integrated  set  of  office  applications  that  includes  word  processing,  calendar 
and  de>k  management,  graphics,  mail,  spread  sheet,  and  other  capabilities. 
Analysts  with  accounts  on  this  node  frequently  use  the  integrated  spread 
sheet,  graphic,  and  word  processing  capabilities  to  prepare  reports  and  pres- 
entation material.  These  can  then  be  either  sent  to  or  made  available  ove*- 
DKCnet  to  others  with  proper  access  to  these  reports.  The  timeliness  with 
which  these  reports  are  prepared  and  distributed  enables  management  to 
react  to  market  shifts  and  adjust  production,  development,  and  advertising 
direction  appropriately. 
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Figure  9-4:    COPY  Request/Response  Is  Shown  Routed  through 
Multiple  Nodes 


The  transfer  of  the  files  to  or  from  the  research  analysts'  systems  uses  the 
DECnet  mechanisms  described  ;n  Chapter  6.  As  noted,  operation  o^  these 
mechanisms  is  completely  transparent  to  the  terminal  users.  Programs  that 
handle  file  transfer  and  reception,  as  described  below,  must  include  proper 
calls  to  network  services. 

9.2.2   Quality  Control  and  Vendor  Analysis 

Programmed  file  transfer  operates  at  Fictional  in  the  interacti(m  between 
quality  control  and  purchasing  systems.  The  quality  control  applications  run 
at  the  company's  manufacturing  locations,  and  the  purchasing  systems  oper- 
ate at  regional  purchasing  centers  (see  Figure  9-5). 


^     MANUFACTURING  FACILITIES 
Q    REGIONAL  PURCHASING  CENTERS 


Figure  9-5:    File  Transfer  between  l\1anufacturing  and  Purcliasing 
Locations 
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In  one  of  the  quality  control  (QC)  operations,  incoming  components  used  in 
product  assembly  are  screened  by  sensors  that  analyze  dimensional  character- 
istics. The  sensors  are  multidropped  from  DECnet-RSX  nodes  that  control 
sensor  operation  and  that  translate  senvsor  input  to  formatted  data. 

Results  of  quality  control  analyses  are  accumulated  by  component/ship- 
ment/vendor/QC  location.  On  a  daily  basis,  a  program  run  in  a  DECnet-VAX 
node  at  each  of  the  plants  accesses  this  information  and  builds  files  by  manu- 
facturing location/date/vendor/shipment/component/QC  location.  It  also  de- 
velops information  on  rejected  items  in  terms  of  units  and  dollar  value  for 
each  vendor/shipment/component  and  for  each  QC  location. 

On  third  shift,  when  systems  and  lines  are  less  busy,  a  data  acquisition  pro- 
gram in  the  purchasing  subsystems  uses  the  DECnet  file  transfer  capability  to 
move  these  files  to  the  regional  purchasing  centers,  where  the  data  is  input  to 
a  vendor  analysis  and  evaluation  program. 


9.3    DE    let's  Remote  File  Access  Capability  in  an  Application 
En.  «onment 

The  file  transfer  capability,  as  described  in  the  preceding  section,  is  a  subset 
of  DECnet's  overall  remote  file  access  capability.  This  capability  enables 
Fictional  programs  and  users  to  transfer  files  from  one  node  to  another,  to 
manipulate  files  on  remote  nodes,  and  to  display  remote  files  at  local  nodes. 
The  DECnet  mechanisms  used  to  perform  these  operations  are  identical  to 
those  used  in  file  transfer. 

9.3.1    Network  Virtual  Terminals 

Another  DECnet  feature  that  supports  extensive  remote  file  access  operation 
at  Fictional  is  the  network  virtual  terminal  capability.  This  capability  enables 
a  user  at  a  terminal  at  one  node  to  log  on  to  a  remote  node  and  operate  as  if 
the  terminal  were  directly  attached  to  that  node.  Users  of  this  capability 
must,  of  course,  have  proper  access  to  the  remote  nodes  and  files. 

Although  the  virtual  terminal  capability  is  exercised  slightly  differently  for 
each  DECnet  implementation,  overall  procedures  are  similar.  The  following 
example  shows  how  a  user  at  a  terminal  on  a  DECnet-VAX  node  would  use 
the  SET  HOST  command  to  log  on  to  a  remote  node  to  use  resources  located 
there. 


$     SET    Hnt^T    ATLANTA 

Username:     i^AlNETv 

Password:    (not    echoed) 

Uelcodie    to    UAX/UMS    Version    3.4    on    node    ATLANTA 
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In  the  above  example,  a  user,  identified  as  RAIXKH.  at  a  terminal  connected 
to  a  DECNF:T-VAX  node,  entered  a  SET  HOST  command  to  lo^  on  to  node 
ATLANTA.  See  Figure  9-6.  The  system  then  asked  RAINKR  for  his  name 
and  password.  The  welcome  mes.sage  that  printed  out  indicates  that  RAINKR 
has  a  valid  account  on  node  ATLANTA.  The  prompt  ($)  that  follows,  shows 
that  RAINER  is  logged  on  to  the  node  and  can  u.se  its  files  and  other  re- 
sources. If  RAINER  did  not  have  a  valid  account  on  that  node,  an  "Unauthor- 
ized User"  message  would  print  out  and  RAINER  would  be  returned  to  his 
local  .system. 


The  following  section  describes  an  application  development  project  currently 
underway  at  Fictional.  This  project  is  expected  to  optimize  the  corporate 
treasurer's  ability  to  identify  and  invest  idle  funds  using  DECnet's  remote  file 
access  capability. 


$  SET  HOST  ATLANTA 


Figure  9-6:    Local  User  Logs  onto  Remote  Node 
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9.3.2   Short-term  Cash  Management 

Corporate  funds  are  kept  in  many  accounts  at  foreign  and  domestic  banks.  A 
short-term  cash  management  application  system  currently  being  developed  at 
Fictional  will  enable  the  corporate  treasurer  to  check  the  status  of  these  funds, 
identify  idle  cash,  and  then  transfer  these  nonworking  assets  to  the  portfolio 
management  group  for  investment,  specify  the  funds  for  debt  reduction,  or 
retain  them  in  the  current  account. 

DECnet's  remote  tile  access  capability  is  a  principal  component  in  this  pro- 
jected capability. 

The  application  development  effort  is  concerned  with  developing  appropriate 
security  measures,  identifying  parameters  and  processing  requirements  that 
will  help  define  "unencumbered  funds,"  with  cross-referencing  regional  data 
bases  for  rel'^vant  cash  and  local  currency  value  data  and  with  developing 
algorithms  that  equate  investment  opportunities  with  available  cash. 

Using  the  communications  capability  provided  by  Gateways,  and  by  DFX- 
net's  remote  file  access  capability  over  local  area,  wioe  area,  X.2o,  and  SNA 
networks,  the  treasurer's  office  will  be  able  to  isolate  and  examine  cash  re- 
cords maintained  in  regional  data  bases  worldwide.  Analysis  of  this  informa- 
tion will  then  enable  the  treasurer  to  make  timely  decisions  as  to  transfer  and 
investment  actions. 

9.4    DECnet's  Terminal  Facilities  in  an  Application  Environment 

DECnet's  terminal  facilities  include: 

•  Interactive  terminal  communications  functions  integrated  into  the  network 
software 

•  Functional  capabilities  that  are  given  broad  distribution  through  DECnet's 
communications  capabilities 

•  Other  capabilities  based  on  DECnet  terminal  configuration  options 

Interactive  terminal  communications,  as  described  in  Chapter  7,  enable 
users  to  communicate  with  one  another  over  the  network  in  real  time. 

DECnet's  communications  capabilities  enable  terminal  users  to  access  lo- 
cally resident  or  remote  processing  capabilities  and  to  distribute  the  output 
over  the  network.  In  other  words,  any  node  in  the  network  can  be  used  as  if  it 
were  the  local  node. 

Configuration  options  enable  users  t^  incorporate  general  purpose  node- 
based  or  terminal  server-based  network  virtual  terminals  into  their  networks. 
As  described  in  Section  7.2,  the  virtual  terminal  capability  enables  you  to  log 
on  to  any  supportive  node  in  the  network  and  use  the  resources  of  that  node. 
Further,  the  ability  to  include  personal  computers  in  a  DECnet  configuration 
and  to  use  them  in  both  processing  and  terminal  emulation  modes  adds  a 
dimension  to  the  terminal  facilities  available  through  DECnet. 

The  following  sections  summarize  some  of  the  ways  in  which  Fictional  Corpo- 
ration uses  these  capabilities  in  its  daily  operations. 
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9.4.1  Order  Entry  and  Production  Scheduling 

Production  scheduling  frequently  sees  some  on-line  communication  between  a 
sales  otiice  and  a  manutacturing  site.  li,  tor  example,  the  sales  office  is  noti- 
fied by  the  production  scheduling  system  that  customer  delivery  recjuirements 
cannot  be  met.  the  sales  office  might  consult  with  the  customer  and  negotiate 
another  acceptable  date  for  delivery  of  ordered  products. 

A  terminal  operator  or  the  salesperson  will  then  invoke  a  DKCnet  interactive 
terminal  facility  (F^hone  or  TLK.  described  in  Chapter  7)  at  a  sales  office 
terminal  and  communicate  revised  delivery  instructions  to  the  manufacturing 
location. 

When  working  at  a  terminal  on  a  DF.Cnet  \'AX  node,  for  example,  the 
salesperson  would  invoke  the  Phone  utility.  See  Figure  9  7.  In  the  example 
that  follows,  a  dialog  is  established  with  a  u^er  at  another  DKCnet  \'AX  node 
at  a  manufacturing  location  named  MF(17. 

$     PMCNE    MFG7: rSCHED 

This  command  places  a  call  to  a  user  named  SCHKI)  at  the  manufacturing 
site.  If  SCHEI)  is  currently  logged  on  to  the  DFCnet  \'AX  node,  a  message 
will  be  displayed  indicating  that  a  message  has  been  received.  If.  for  example, 
the  sender  is  a  user  named  (iHFKN  at  a  node  called  SAI.KS4.  the  message 
will  read  as  follows: 

SALESa:  :GrvEEN     is     Phonms     v  o  u     on    MFG7 

To  receive  and  respond  to  the  call.  SCHP'.I)  enters: 

$    Phone  answer 

This  reply  causes  both  terminals  to  display  a  split  screen.  The  top  half  of  the 
screen  displays  the  local  user's  input  and  the  bottom  half  displays  the  remote 
user's  input.  Each  party  to  the  dialog  can  enter  text  at  the  same  time. 

After  using  this  facility  at  Fictional  to  arrive  at  a  mutually  acceptable  sched- 
ule for  production  and  customer  delivery,  the  manufacturing  location  specifies 
it  back  to  the  production  scheduling  data  base  at  corporate  headquarters. 

Fictional  finds  that  informal  interaction  outside  the  applications  frequently 
resolves  such  customer  service  issues  more  quickly  than  do  sets  of  systema- 
tized procedures.  DECnet  interactive  terminal  communications  support  such 
activities  throughout  the  network. 

9.4.2  y^irket  Research 

Becf  use  effective  market  research  must  be  responsive  to  current  market 
trends,  market  re.search  analysts  at  Fictional  develop  forecasts  and  test  new- 
product  mar'f.eting  strategies  in  real  time.  Field  input  is  played  against  mar- 
ket models;  results  are  analyzed  by  statistical  processing  capabilities,  and 
"what  if  input  is  developed  to  refine  and  extend  the  models. 
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Figure  9-7:    Phone  Capability  Permits  Rapid  Communication  between 
Users 

Research  analysts  use  DECnet's  terminal  facilities  extensively  in  performing 
this  work.  Field  analysts  provide  input  via  VTIOO  lerminals  connected  to 
nodes  at  regional  locations.  Analysts  at  corporate  headquarters  use  VT125 
terminals  connected  to  a  DECnet-VAX  node  with  node-resident  ALL-IN-1 
software  capabilities  to  develop  reports  and  presentation  material. 

In  report  development,  the  analysts  use  the  integrated  ALL-IN-1  software 
capabilities  to  combine  spread  sheet  computation,  graphics  development,  and 
word  processing.  When  required,  the  mail  capability  of  ALL-IN-1  is  called  up 
to  distribute  reports  and  analyses  over  the  network. 

In  addition  to  the  integrated  mail  capability  provided  by  ALL-IN-1,  several 
similar  capabilities  are  available  to  DECnet  users  who  might  not  need  all  of 
the  capabilities  of  the  integrated  package.  The  VMS  MAIL  capability,  for 
example,  enables  users  at  DECnet-VAX  nodes  to  exchange  correspondence. 

To  send  a  message,  the  user  simply  enters  the  MAIL  command,  specifies  the 
SUBJECT  of  the  correspondence,  and  either  specifies  a  file  to  be  sent  or  types 
the  message  in  response  to  a  prompt.  For  example: 

♦  MAIL/SUBJECT  =  20NE12  UrOATE.ilKT  LONDON  ::  GT  AHAM 
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This  command  lir.  delivers  the  contents  of  the  file,  IfPDATFl.MKT,  to  a  user 
named  GRAHAM  at  nod-  LONDON.  It  (IRAHAM  is  logged  on  to  node  LON- 
DON, a  message  such  as  the  following  appears: 


New  mail  from  YORK  :: PEEK 


This  line  indicates  that  the  waiting  message  is  from  a  user  named  PEEK  at 
node  YORK.  To  read  the  mail.  GRAHAM  enters  the  MAIL  command  and 
presses  RET.  A  message  is  displayed: 


Yoij    hai'e     1     new    mail    message 
MAIL> 


GRAHAM  presses  RET  in  response  to  this  prompt  and  the  mail  sent  by 
PEEK  is  displayed  on  the  screen. 

Mail  sent  to  a  terminal  that  is  not  logged  on  to  a  node  is  indicated  to  the  user 
of  that  terminal  at  the  next  log  in. 

9.4.3    Short-term  Cash  Management 

The  PRO/DECnet  node  in  the  treasurer's  office  is  connected  with  an  Ethernet 
local  area  network  cable  that  serves  the  department  and  other  adjacent 
groups.  This  personal  computer  serves  the  treasurer  in  several  ways: 

•  As  a  stand  alone  processor  with  its  own  self-contained  file  and  disc  services 

•  As  a  node  on  the  DECnet  network,  capable  of  interacting  with  computing 
capabilities  and  other  resources  located  elsewhere  on  the  network 

•  As  a  terminal  on  the  DECnet  network  that  can  access  other  nodes  and  use 
resources  located  at  those  nodes 

The  network  mail  services  available  to  the  treasurer  through  this  node  or 
through  another  host  node  on  the  network  will  be  of  significant  value  when  the 
short-term  cash  managment  application  is  fully  implemented. 

Decisions  to  use  available  cash  must  take  into  account  both  internal  and 
external  factors  in  a  very  dynamic  environment.  Internal  factors  are  repre- 
sented by  such  considerations  as  payables,  operating  requirements,  debt  cons- 
traints, and  so  forth.  External  factors  (such  as  bank  policies  in  regard  to 
minimum  balances,  for  example)  are  important  considerations  in  determining 
thresholds  that  define  caeh  as  excess.  Such  policies,  however,  are  frequently 
conditioned  by  the  general  economic  climate,  government  regulations  in  re- 
gard to  fund  transfer,  as  well  as  other  uncertainties  that  govern  international 
financial  transactions. 

Using  the  mail  and  dialog  facilities,  the  treasurer  can  keep  informed,  in  real 
time,  of  actual  or  potential  changes  in  such  conditions.  Fund  accumulations 
can  be  monitored  along  with  those  conditions  that  can  affect  movement  of 
those  funds. 
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Records  ot  intbrmation  that  inHuence  investment  ('ccisions  ran  be  retained  on 
line  tor  quick  lookup  and  can  also  be  printed  out  it  hard  copy  is  desired.  This 
kind  of  intbrmation  will  enable  the  treasurer  to  optimize  decisions  in  regard  to 
existing  and  potential  inventories  of  investable  funds. 

9.5    DECnet  as  a  Consideration  in  Relocation  Planning 

In  planning  relocation  ot  its  corporate  headquarters.  Fictional  Corporation 
management,  along  with  a  group  of  outside  consultants,  carefully  examined 
the  consequences  that  the  projected  move  could  have  on  future  operations. 

The  company  planned  to  move  to  an  exurban  location,  outside  the  commuting 
distance  of  a  major  metropolitan  area.  Real  estate  c{)sts  and  tax  advantages 
were  attractive;  a  dependable  labor  po('i  was  available;  and  the  projected 
location  was  also  desirable  in  terms  of  cultural  and  recreational  activities  tbr 
employees. 

The  expense  to  be  incurred,  however,  was  significant.  Architectural  tees  and 
construction  costs,  along  with  the  outlay  required  to  relocate  existing  employ- 
ees who  decided  to  go  along  with  the  move,  represented  a  very  sizeable  invest- 
ment. Major  questions  arose  concerning  the  threat  posed  to  this  investment  it, 
in  the  future,  a  decision  was  made  to  change  the  company's  structure.  Would 
the  physical  shell  into  which  they  planned  to  move  threaten  to  define  the 
logical  structure  from  which  they  would  continue  to  operate,  even  if  future 
business  considerations  dictated  change'^ 

What,  for  example,  would  happen  if  Fictional  decided  to  sell  a  subsidiary 
operation,  or  to  decentralize  certain  operations  that  were  now  centralized,  or 
to  realign  intergroup  and  reporting  relationships'^  Management  realized  that 
in  moving  from  its  current  urban  location.  Fictional  would  be  cutting  itself  off 
from  the  numerous  services  —  such  as  availability  of  rental  space  and  a 
market  for  subleasing  —  that  are  common  tf)  a  metropolitan  environment. 
Would  the  new  physical  plant  in  its  proposed  location  —  and  built  at  great 
expense  —  be  flexible  enough  to  continue  serving  a  changing  organization'^* 

Together  with  the  consultants.  Fictional  management  determined  that  recent 
developments  in  computer  technology,  such  as  those  offered  by  DECnet,  are 
new  and  positive  elements  to  be  considered  in  dealing  with  such  questions. 
Local  area  networks,  for  example,  permit  those  changes  in  information  flow 
that  accompany  reporting  and  administrative  realignment  to  be  put  in  place 
rapidly,  without  disrupting  ongoing  business.  Meanwhile,  communication 
with  facilities  anywhere  in  the  world  continues  to  use  network  facilities  that 
are  already  in  place. 

In  dealing  with  these  matters,  Fictional  learned  that  investment  in  relocation 
is  afforded  a  degree  of  protection  by  flexible  and  responsive  computer  commu- 
nications facilities,  such  as  DECnet,  even  through  changes  in  business  struc- 
ture. Computer  networking,  it  was  determined,  provided  a  measure  of  mobil- 
ity to  capital  investment. 
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Chapter  10 

Network  System  Management 


This  chapter  outlines  the  network-related  tasks  of  a  DECnet  system  manager 
and  describes  the  facilities  that  DPX^net  provides  to  perform  those  tasks.  In  so 
doing,  the  chapter  also  provides  many  definitions  of  network  entities  and 
parameters  that  pertain  to  network  system  management.  In  practice,  many 
people  may  be  responsible  for  carrying  out  the  described  tasks.  For  simplicity, 
these  people  are  collectively  defined  by  the  job  title  "system  manager."  Those 
who  manage  network  nodes  are  responsible  to  both  local  and  remote  users  and 
should  be  aware  that  while  local  applications  usually  demand  the  greatest 
share  of  system  resources,  the  remote  users,  a  potentially  very  large  group, 
must  be  sure  of  each  node's  response  to  nttwork  applications. 

The  procedures  for  performing  network  management  functions  can  vary  from 
system  to  system.  For  example,  the  procedure  for  generating  a  DECnet/E 
node  is  different  from  the  procedure  for  generating  a  DECnet-RSX  node. 
RSTS/E  is  a  time-sharing  system  with  a  .software  structure  quit  '  unlike  the 
real-time,  event-driven  RSX-llM.  Because  each  DECnet  imr lementation 
(DECnet/E,  DECnet-VAX,  and  so  on)  is  an  extension  of  an  operating  system, 
the  different  ways  to  manage  a  node  reflect  the  differences  between  the  basic 
Digital  operating  systems.  The  purpose  of  this  chapter  is  to  provide  an  over- 
view of  network  management  functions  rather  than  to  describe  actual  proce- 
dures for  performing  them.  Procedural  information  can  be  found  in  the  docu- 
mentation provided  for  a  specific  implementation. 

Network  system  management  functions  in  DECnet  include: 

•  Planning  for  node  generation  (.see  Section  10.2).  This  process  tailors 
DECnet  software  to  suit  a  specific  node's  network  application.  Node  genera- 
tion planning  should  be  conditioned  by  an  overall  network  plan  that  estab- 
lishes basic  network-wide  conventions.  Implementation  of  such  conventions 
will  assure  communications  and  processing  capability  throughout  the  net- 
work. 

•  Generating  network  software  (see  Section  10.3).  This  section  discusses 
building  the  tailored  DECnet  software  to  create  an  active  node. 

•  Defining  and  redefining  network  parameters  (see  Section  10.4).  This 
section  introduces  various  network  parameters  whose  definitions  determine 
many  aspects  of  a  node's  role  within  a  specific  DECnet  configuration. 
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•  Operating  &  node  (see  Section  10.5).  This  section  discusses  operational 
functions  such  as  starting  up  and  shutting  down  a  node  and  the  physical 
lines  connected  to  a  node. 

•  Monitoring  node  activity  (see  Section  10.6).  This  section  discusses  moni- 
toring the  day-to-day  performance  of  a  node  by  gathering  and  analyzing 
logging  data  that  DECnet  makes  available. 

•  Down-iine  loading  (see  Section  10.7).  This  section  discusses  the  procedure 
for  loading  system  and  task  images  from  an  executor  node  to  satellite  nodes 
such  as  RSX-llS  and  communication  server  nodes. 

Network  system  management  responsibilities  also  include  the  testing  and 
monitoring  functions  described  in  Chapter  11. 

10.1  Network  Management  Utilities 

Network  management  utilities  are  the  means  by  which  a  system  manager 
performs  most  of  the  functions  described  in  this  chapter.  All  DECnet  imple- 
mentations support  one  or  more  utilities  that  provide  access  to  DECnet  man- 
agement modules.  These  modules  perform  the  functions  defined  by  the  Net- 
work Management  layer  (see  Section  1.3.1).  A'!  implementations  support  a 
utility  called  the  Network  Control  Program^  (NCP). 

Table  10-1  briefly  describes  the  function  of  NCP  and  other  network  manage- 
ment utilities  that  each  DECnet  implementation  uses.  Each  utility  accepts 
commands  that  activate  DECnet  management  modules  either  to  perform  spe- 
cific tasks  or  to  request  information  about  the  current  state  of  the  local  node 
or  the  network.  Each  utility  is  described  in  detail  in  the  system  manager's  or 
user's  guide  for  each  DECnet  implementation. 

10.2  Planning  for  Node  Generation 

Planning  for  node  generation  entails  gathering  and  consolidating  information. 
Digital-supplied  DECnet  software  provides  generalized  network  capabilities, 
but  the  user  must  supply  the  data  and  programs  that  create  a  live  DECnet 
application.  A  system  manager  accumulates  these  data  and  programs  for 
eventual  incorporation  into  the  local  node. 

Each  system  mar  uger  must  ensure  that  managers  elsewhere  in  the  network 
receive  information  that  they  need  about  other  nodes.  Programmers  responsi- 
ble for  network  applications  should  cooperate  with  system  managers  by  ex- 
changing information.  For  example,  programmers  must  use  correct  addresses 
in  calls  thai  generate  connect  requests  (see  Section  5.1),  while  system  .nana- 
gers  must  know  the  correct  names  and  object  types  that  the  network  programs 
use  to  identify  themselves. 
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Table  10-1:    DECnet  Systems  and  Network  Management  Utilities 
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System 

DECnet-VAX 


DECnet-RSX 


DKCnet/E 


DECnet-IAS 


DECnet  RT 


DErnet-20 


DECnet-lO 


Legend: 


Utility         Function 

NCP  Loads,  controls,  monitors,  and  tests  DECnet  software;  de- 

fines configuration  data  base  parameters;  down-line  loads 
DECnet/llS  and  communication  server  nodes 

NCP  Loads,    controls,    monitors,    and   tests   DECnet    software; 

down-line  loads  DECnet/llS  and  communication  server 
nodes 

CFE  Changes     parameters     in     the     configuration     file     CE- 

TAB.MAC.  which  is  produced  at  network  generation 

VNP  Changes  the  disk  image  of  a  DECnet  RSX  system  (VNP 

cannot  be  run  from  a  DECnet/llS  node) 

NCP  Loads,    controls,    monitors,    and   tests   DECnet    software; 

maintains  the  DECnet/E  parameter  file;  reports  the  cur- 
rent status  of  active  logical  links,  of  known  physical  lines 
and  remote  nodes,  and  of  programs  using  local  and  remote 
send/receive  services 

NCP  Loads,  controls,  monitors,  and  tests  DECnet  software;  de- 

fines configuration  data  base  parameters 

CFE  Changes     parameters     in     the     configurati(m     file     CE- 

TAB.MAC.  which  is  produced  at  network  generation 

NCP  U)ads.  controls,  monitors,  and  tests  DECnet  software;  de- 

fines and  changes  configuration  data  base  (CETAB.MACi 
parameters 

NCP  Loads,  controls,  mtmitors,  and  tests  DF^Cnet  software;  de- 

fines the  configuration  data  base:  d'  wn-line  loads  system 
and  task  images 

NCP  Loads,  controls,  monitors,  and  tests  DECnet  sottware;  de- 

fines the  configuration  data  base;  d'/An-line  loads  system 
and  task  images 


CFE  —  Configuration  File  Editor 
NCP  —  Network  Control  Program 
\'NP  —  Virtual  Network  Processor 


10.2.1    Configuration  Data  Bases 

Every  DECnet  node  has  some  form  of  configuration  data  base  that  defines 
characteristics  of  the  local  node  and  determines  how  that  node  functions 
within  the  network.  In  some  cases,  Digital-supplied  software  already  Includes 
such  a  data  base  to  provide  initial  default  values  for  many  data  base  entries. 
For  other  implementations,  the  network  generation  procedure  creates  the  data 
base.  Table  10-2  lists  the  term  that  each  DECnet  implementation  uses  to 
identify  its  configuration  data  base. 
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Depending  on  the  type  ofDECnet  node,  the  configuration  data  base  may  need 
to  be  updated  periodically  to  reflect  changes  in  the  network  or  to  tune  the 
performance  of  the  network.  Section  10.4  explains  many  of  the  parameters 
typically  included  in  a  configuration  data  base.  The  facts  and  figures  needed 
to  define  them  must  be  gathered  before  a  node  can  actively  participate  in  a 
network. 
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Table  10-2:    Configuration  Data  Base  Terms 


System 

DECnet-VAX 


DECnet  RSX 
DPXnet-lAS 


DEC  net /E 
DECnet-RT 


DEC  net -20 


DECnet-10 


Term 

Configuration     data 
base 


Configuration  file 


Parameter  file 
Configuration  file 


m-CO\FIG.CMD 


nodenamp.CSF 
NETPAR.MAC 

Configuration  file 


Configuration  files 


Comments 

The  initial  data  base  is  provided  within  the 
DECnet  software  supplied  by  Digital.  N'CP 
commands  are  subsequently  used  to  modify 
the  data  base. 

This  file  (CETAB.MAC)  is  created  during 
network  generation  and  subsequently  can  be 
modified  by  the  Configuration  File  Editor 
(CFE). 

l^his  file  (SNETPRM.SYS)  is  created  and 
subsequently  modified  by  N'CP  commands. 

This  file  (CETAB.MAC)  is  created  during 
network  generation  and  subsequently  can  be 
modified  by  network  management  com- 
mands. 

This  file  is  shipped  with  the  TOPS-20  moni- 
tor and  modified  by  the  installer  to  define  the 
local  hardware  configuration. 

This  is  the  network  configuration  file.  This 
file  contains  .system-specific  parameters. 

This  file  (CETAB.MAC)  is  created  during 
network  generation  and  subsequently  can  be 
modified  by  network  management  com- 
mands. 

These  files  (mapping. CSF  and  CE- 
TAB.MAC) are  created  during  network  gener- 
ation and  subsequently  can  be  modified  by 
network  management  commands. 
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10.2.2    Network  Generation  Planning  Aid 

DECnet-IAS  and  DECnet-RT  each  provide  an  aid  to  help  users  plan  for  node 
generation.  The  aid  consists  of  a  command  file  tliat  contains  questions  per- 
taining to  node  generation  options.  A  system  manager  runs  this  command  file 
from  a  terminal  and  answers  the  questions  according  to  the  requirements  of 
the  local  node. 
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Using  the  system  manager's  responses,  the  command  file  then  generates  sev- 
eral worksheets.  Each  worksheet  tells  the  system  manager  how  to  generate 
some  part  of  DECnet  to  retlect  local  requirements.  See  the  appropriate  net- 
work generation  manual  for  a  complete  description  of  the  command  file  and 
the  worksheets  it  generates. 

10.3  Generating  Network  Software 

DECnet  software  arrives  from  Digital  on  distribution  media  such  as  magnetic 
tapes  or  floppy  disks.  The  type  of  medium  depends  on  the  DECnet  implemen- 
tation and.  in  some  cases,  on  the  hardware  configuration  of  a  specific  system. 
For  example.  DECnet-RSX  is  distributed  on  several  media  to  accommodate  a 
variety  of  user  hardware  configurations. 

The  procedures  for  using  the  distributed  software  to  generate  an  active  node 
are  different  for  each  implementation  of  DECnet.  To  generate  an  RSX  or  an 
IAS  node,  a  system  manager  has  to  regenerate  the  operating  system  first  and 
then  tailor  and  build  the  network  application  on  top  as  a  second  procedure. 
Other  implementations  do  not  require  a  system  manager  to  rebuild  the  dis- 
tributed software. 

A  specific  list  of  DECnet  software  modules  depends  on  the  implementation 
and  on  the  specific  network  application.  However,  the  distributed  software 
can  include  modules  like  the  ones  listed  below,  many  of  which  have  been 
discussed  in  preceding  chapters. 

•  Network  device  controllers 

•  A  DDCMP  module 

•  Ethernet 

•  Routing  layer  modules 

•  An  NSP  module 

•  Network  utilities  like  NCP,  NFT,  and  TLK 

10.4  Defining  Configuration  and  Other  Static  Parameters 

The  parameters  that  make  up  a  node's  configuration  data  base  are  relatively 
permanent  or  static,  because  changing  them  tends  to  change  the  way  the  node 
functions  within  the  network.  In  addition  to  parameters  that  are  strictly  part 
of  a  configuration  data  base,  a  system  manager  must  define  other  parameters, 
such  as  local  node  network  object  descriptions  (see  Section  5.2.1.1),  that  affect 
the  way  a  node  functions  within  a  network. 

Depending  on  the  implementation,  configuration  and  other  static  parameters 
are  defined  in  various  ways.  They  can  be  defined  at  network  generation  by 
means  of  NCP  commands,  or  they  may  be  predefined  in  Digital-supplied 
software.  Brief  descriptions  of  static  parameters  that  are  typically  defined  for 
most  types  of  DECnet  nodes  are  provided  in  the  following  subsections. 
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10.4.1  Node  Addresses  and  Names 

The  system  manager  must  assign  a  numeric  address  that  uniquely  identifies 
that  node  within  the  network.  See  Section  2.1  for  a  discussion  of  node  ad- 
dresses and  node  names. 

10.4.2  Node  Verification  Passwords 

Whenever  one  of  its  physical  lines  is  turned  on,  a  node  exchanges  initializa- 
tion messages  with  the  remote  node  at  the  other  end  of  the  line.  (Section 

10.5.2  discusses  starting  up  a  physical  line.)  The  messages  exchange  informa- 
tion such  as  the  version  numbers  of  the  node's  DECnet  software  modules  or 
the  node's  type  —  routing  or  nonrouting. 

After  exchanging  initialization  messages,  a  node  can  request  that  the  adjacent 
node  verify  its  identity  by  supplying  a  password.  If  such  verification  is  re- 
quired, adjacent  nodes  must  supply  passwords  to  gain  access  to  the  local 
node.  If  verification  is  not  required,  adjacent  nodes  do  not  have  to  supply 
passwords,  and  they  automatically  gain  access  to  the  local  node  after  ex- 
changing initialization  messages.  The  access  gained  or  denied  at  this  stage  has 
to  do  with  the  ability  to  send  and  receive  messages  over  the  physical  line 
connecting  two  nodes. 

Within  a  DECnet  configuration  that  enforces  node  verification,  each  node 
maintains  a  data  base  of  passwords  that  it  sends  to  and  expects  to  receive 
from  its  neighbors: 

•  Receive  password.  The  password  that  the  local  node  expects  to  receive 
from  the  adjacent  node.  If  the  password  actually  received  does  not  match 
the  receive  password  expected,  the  local  node  denies  access  to  the  adjacent 
node. 

•  Transmit  password.  The  password  that  the  local  node  sends  to  the  adja- 
cent node.  The  transmit  password  must  match  the  receive  password  that 
the  adjacent  node  expects  from  the  local  node. 

10.4.3  Networic  Object  Parameters 

Most  nodes  maintain  a  data  base  that  describes  all  the  network  objects,  both 
user-written  programs  and  DECnet  modules,  currently  residing  in  the  node 
and  capable  of  engaging  in  network  activity.  (Network  objects  are  described 
in  Section  5.2.1.)  The  manner  in  which  the  node's  object  data  base  is  main- 
tained depends  on  each  node's  implementation.  Typically,  a  node  stores  the 
following  kinds  of  information: 

•  Object  types,  names,  and  addresses 

•  Access  control  and  verification  information  associated  with  each  object 

•  The  number  of  copies  of  a  specific  object  that  DECnet  can  run  to  satisfy 
incoming  connect  requests 
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10.4.4    Routing  Pararrieters 

vSeveral  parameters  affect  the  operation  of  the  routing  module  in  Phase  III  and 
Phase  IV  full-r(»uting  nodes.  (See  Chaptci  2  for  a  discussion  ol  full  routing.) 
These  parameters  establish  characteristics  such  as: 

•  A  maximum  path  cost  that  limits  possible  routes  to  paths  that  cost  the 
same  as  or  less  than  this  value. 

•  Individual  line  costs  that  figure  in  routing  algorithms  used  by  the  routing 
module.  Each  line  cost  is  a  number  from  1  to  the  maximum  path  cost  set  for 
the  node.  Higher  line  cost  can  lead  to  less  traffic  on  the  line  because  the 
routing  modules  dispatch  packets  on  the  least  costly  paths.  Lowering  the 
cost  of  a  line  does  not  always  increase  the  traffic  it  carries.  For  example,  if  a 
line  leads  to  an  end  node,  line  cost  does  not  affect  that  line's  traffic. 

If  one  or  more  of  a  node's  lines  actually  cost  more  than  others  to  use,  the 
traffic  on  those  lines  can  possibly  be  diminished  by  raising  the  routing  line 
costs  assigned  to  them.  In  fact,  this  can  be  done  whenever  the  system 
manager  wants  to  decrease  traffic  on  a  line. 

•  A  maximum  number  of  hops  per  path.  A  node  is  unreachable  if  it  cannot  be 
reached  within  the  maximum  number  of  hops. 

•  A  routing  timer  that  determines  the  interval  between  automatic  updates  of 
the  local  node's  nniting  data  base. 

•  A  liuffer  size  for  the  unit  of  data  actually  transmitted  over  physical  lines  by 
the  transport  module. 

•  A  buffer  count  that  determines  the  size  of  the  routing  module's  pool  of 
available  buffers. 


# 


10.4.5    Line  Identification 

Each  communication  line  leading  from  a  node  has  a  unique  identification  that 
is  used  in  commands.  A  node's  configuration  data  base  usually  contains  the 
identification  of  each  communication  line.  This  identification  has  the  follow- 
ing general  format: 

dei-c-u 

where 

dev      is  a  mnemf)nic  for  the  type  of  device  —  for  example: 

UNA  —  the  DUENA  multiaccess  communications  link  (Ethernet) 

DUP  -  theDUPll-DA 

DMC  -  the  DMCll-DA/AR.  -MA,  AL,  or  FA/AR 

DZ  -  the  DZll-Aor-B 

c  is  a  number  (0  or  a  positive  integer)  designating  the  device's  hardware 

controller. 


• 


u         is  a  unit/line  number  (0  or  a  positive  integer)  included  if  the  device  is  a 
multiplexer. 


Network  System  Management       10-7 


FCxaniples  of  line  identii'ication  follow: 
Identification  Description 

INA  0  1)1  KNA.  toiuniiler  l) 

DMR  0  DMHll.  (ontroller  0 

l)Z   1  0  DZll.  controller  1.  unit  0 


10.4.6  Circuit  Parameters 

In  '■  dition  to  identifying  actual  physical  lines,  most  PECnet  implementa- 
tions also  identify  circuits,  which  are  logical  p(^int-to-noint  communications 
{)aths.  At  nodes  with  these  implementations,  the  circuit  '  ..ther  than  the  line  is 
manipulated  and  defined  to  control  the  tlovv  of  data  hetween  nodes.  Physical 
lines  become  the  medium  over  which  circuits  operate.  As  a  reflection  of  this 
concept.  DECnet-VAX.  DEC'net  HSX.  nErnet-20.  DECnet  10.  and  DEC- 
net/E  users  frequently  specify  circuits  when  users  at  other  DECnet  nodes 
specify  lines  in  equivalent  network  managenieni  commands. 

Circuits  thi>t  handle  DECnet  traffic  correspond  closely  to  the  physical  lines 
that  actually  transmit  the  data.  When  a  circuit  corresponds  to  a  point-to- 
point  line,  circuit  IDs  and  line  IDs  are  exactly  the  same.  For  example,  the 
string  DMC-O  can  identify  either  the  line  or  the  circuit  in  a  network  manage- 
ment command.  However,  circuit  and  line  identifications  associated  with  a 
multipoint  line  and  its  tributaries  differ  slightly.  Section  10.4.7  explains  how 
they  differ.  At  a  DECnet -RSX/FSI  node,  DLM  circuits  to  be  mapped  to  PSI 
are  not  associated  with  specific  physical  lines.  The  identification  of  such  a 
circuit  starts  with  the  mnemonic  DLM. 

For  each  circuit,  the  system  manager  must  design  various  parameters,  which 
differ  depending  on  the  type  of  circuit  (for  example,  whether  it  is  associated 
with  a  DDCMP  point-to-point  or  multipoint  line  or  with  a  PSI  virtual  cir- 
cuit). See  the  appropriate  system  manager's  guide  for  further  information 
about  your  system's  circuit  parameters. 

10.4.7  Multipoint  Line  and  Circuit  Parameters  ;  , 

A  multipoint  line  is  a  single  communications  line  connected  to  more  than  tw 
nodes.  (A  line  connecting  two  nodes  is  called  a  point-to-point  line.)  The  DEC- 
net implementations  supporting  multipoint  are  the  Phase  III  and  Phase  IV 
versions  of  DECnet -VA...  and  DFlCnet-RSX  and  the  Phase  III  versions  of 
DECnet/E  and  DECnet  RT.  Figure  10  T  is  a  diagram  of  a  multipoint  line, 
showing  multipoint  components. 

The  control  station  is  the  device  controller  responsible  for  overseeing  data 
transmission  to  and  from  all  the  nodes  attached  to  the  line.  The  devices 
attaching  the  f)ther  nodes  to  the  line  are  called  tributaries.  A  DECnet-RSX, 
DECnet- VAX.  or  a  DECnet/P^  node  can  support  either  a  control  station  or  a 
tributary  device.  A  DECnet-RT  node,  on  the  other  hand,  can  support  only  a 
tributary  device  on  a  multipoint  line. 


• 
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Device  controller   control  station  tor  multipoint  line 
(for  example,  a  DV.  KDP.  KDZ,  DMP.  or  DMV) 


TRIBUTARIES 


LEGEND 

DV 

KDP 

KDZ 

DMP 

DMV 


DV11-AA/BA  synchronous  line  multiplexer 
KMC11/DUP11-DA  synchronous  line  multiplexer 
KMC11/DZ-11-A  asynchronous  line  multiplexer 
DMP11  synchronous  link 
DMV11  synchronous  link 


Figure  10-1:    A  Multipoint  Line 


From  the  perspective  of  the  control  station,  the  multipoint  line  and  the  tribu- 
taries connected  to  it  constitute  a  single  line,  but  the  separate  paths  to  each 
tributary  represent  individual  circuits.  A  multipoint  line,  therefore,  has  more 
than  one  circuit  associated  with  it.  (Figure  2-1  illustrates  the  relationship 
between  a  multipoint  line  and  the  circuits  that  correspond  to  its  tributaries.) 

A  tributary  supports  only  one  physical  link  to  the  control  station.  From  the 
tributary's  perspective,  the  DDCMP  line  that  links  it  to  the  control  station  is 
point-to-point.  The  line  and  corresponding  circuit  are  therefore  equivalent. 

In  the  context  of  full-routing  implementations,  whether  or  not  a  node  supports 
a  conti  1  station  or  a  tributary  on  a  multipoint  line  is  not  significant.  The 
mechanisms  for  handling  data  transmission  on  multipoint  lines  are  transpar- 
ent to  the  modules  in  the  Routing  layer  of  the  architecture. 

At  the  control  station's  node,  a  system  manager  needs  to  define  several 
parameters  that  affect  the  operation  of  the  multipoint  line  and  its  correspond- 
ing circuits: 

•  Tributary  addresses.  The  data  base  at  the  control  station's  node  must 
coniain  correct  tributary  addresses.  The  system  manager  must  therefore 
record  the  unique  decimal  line  address  of  each  tributary  on  the  line. 

•  Polling  ratios.  Whenever  necessary,  the  control  station  delivers  data  ad- 
dressed to  tributaries  under  its  control.  In  order  to  handle  data  originating 
from  its  tributaries,  the  control  station  periodically  polls  them;  that  is,  the 
control  station  periodicrilly  asks  each  tributary  whether  it  has  data  w£;i*'n{: 
to  be  transmitted.  Whi»n  the  control  station  polls  a  tributary  that  has  such 
data,  it  all'^ws  the  tributary  to  transmit. 
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The  frequency  with  which  a  tributary  is  polled  depends  on  the  frequency  of  itr. 
data  transmissions.  For  efficiency,  the  control  station  polls  active  tributaries 
more  often  than  inactive  or  dead  tributaries.  A  dead  tributary  is  one  that  has 
not  responded  within  a  predefined  period  of  time. 

A  system  manager  can  exercise  control  over  the  polling  of  specific  tributaries. 
If  for  some  reason  a  tributary  should  not  be  polled  as  often  as  others,  the 
system  manager  can  issue  a  command  to  assign  an  active  polling  ratio  to  that 
tributary.  A  command  can  also  be  issued  to  set  a  dead  polling  ratio  that 
applies  to  all  inactive  tributaries. 

A  polling  ratio  is  a  number  from  1  to  255.  If  a  tributary's  active  polling  ratio  is 
5,  the  control  station  passes  through  the  active  polling  list  five  times  before 
polling  that  particular  tributary.  (DECnet/E  does  not  implement  the  polling 
technique  discussed  here.) 

10.4.8   Transmission  Moce 

The  system  manager  sets  the  transmission  mode  for  every  line  or  circuit 
connected  to  the  node.  The  transmission  mode  is  either  half  duplex  or  full 
duplex.  See  Section  2.2.1  for  a  definition  of  these  terms. 


10.5    Operating  a  Node 


To  start  up  a  node,  a  system  manager  or  operator  issues  commands  from  a 
terminal  to  load  and  activate  required  DECnet  software  and  to  turn  on  physi- 
cal communication  lines.  In  response  to  the  start-up  procedure,  the  local 
DECnet  software  initializes  the  DECnet  software  in  adjacent  nodes  connected 
by  the  activated  lines  (see  Section  10.4.2).  Shutting  down  the  node  reverses 
the  procedure;  commands  are  issued  to  halt  network  activity  involving  the 
local  node,  to  shut  off  physical  line^,  and  to  unload  DECnet  sc,  ware. 

10.5.1    Controiiing  the  State  of  a  Node 

For  most  implementations  of  DECnet,  a  system  manager  turns  a  node  on  and 
off  by  manipulating  the  node's  state;  for  example: 

NCP:>SET    EXECUTOrv    STATE    ON 

This  command  activates  the  DECnet  software  at  the  node  currently  defined 
to  be  the  executor.  The  executor  is  the  node  at  which  the  NCP  command 
actually  executes.  The  system  manager,  using  an  NCP  command,  determines 
whether  the  executor  is  the  local  or  a  remote  node. 

Most  DECnet  implementations  define  three  distinct  node  states:  ON,  SHUT, 
and  OFF. 

•  ON.  The  local  node  is  enabled  fo;  performing  network  functions. 

•  SHUT.  The  node  maintains  all  existing  logical  links  but  does  not  permit  any 
new  links  to  be  created.  When  existing  links  are  disconnected,  the  node's 
state  changes  to  OFF. 

•  OFF.  The  local  node  cannot  participate  in  any  network  activity,  and  exist- 
ing logical  links  are  aborted. 
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10.5.2   Controlling  Line  or  Circuit  State 

A  node  cannot  actively  participate  in  a  network  until  one  or  more  communica- 
tion lines/circuits  have  been  turned  on.  By  issuing  an  NCP  command,  a 
system  manager  sets  the  state  of  a  line/circuit  to  ON,  OFF,  or  SERVICE: 

•  ON.  The  line/circuit  is  available  for  use  by  the  DECnet  software  responsible 
for  routing  data  packets.  When  a  line/circuit  is  turned  on,  the  local  node 
exchanges  initialization  messages  and,  optionally,  node  passwords  with  the 
remote  node  at  the  other  end  of  the  line/circuit,  provided  that  the  owner  of 
the  line/circuit  is  NSP,  the  default  condition  (see  Section  10.4.2). 

•  OFF.  The  line/circuit  is  not  available  for  any  kind  of  network  activity. 

•  SERVICE.  The  line/circuit  is  available  for  special  network  functions  only: 
down-line  loading,  up-line  dumping,  or  loopback  testing.  (Note  that  some 
implementations  of  DECnet  do  not  recognize  SERVICE  as  a  state  explicitly 
separate  from  ON;  such  implementations  may  impose  the  SERVICE  state 
on  a  line/circuit  by  their  own  internal  means.) 

When  a  line/circuit  is  in  the  ON  state,  DECnet  software  exercises  the  data 
link  protocol  that  ensures  data  integrity  and  sequentiality  for  normal  network 
transmissions.  (The  standard  DECnet  protocol  for  normal  traffic  is  DDCMP.) 
In  the  SERVICE  state,  a  line/circuit  transmits  data  embedded  in  a  protocol 
provided  for  the  special  network  functions.  The  standard  protocol  for  these 
functions  is  called  the  Maintenance  Operation  Protocol  (MOP). 


10.6    Monitoring  Node  Activity 


At  each  node,  DECnet  continuously  monitors  the  current  state  of  the  node  as 
well  as  its  ongoing  performance.  A  system  manager  can  use  network  manage- 
ment utilities  to  display  the  following  information  at  a  terminal: 

•  The  current  state  of  local  and  remote  nodes  and  of  physical  lines 

•  Values  currently  defined  for  configuration  data  base  and  other  static  param- 
eters 

•  The  contents  of  various  counters  that  DECnet  software  maintains  to  track 
network  performance 

In  addition  to  displaying  information  on  request,  DECnet  automatically  logs 
certain  events  both  at  the  operator's  console  and  in  a  file.  Note  that  mote 
system  consoles  at  executor  nodes  can  monitor  operation  of  the  Phase  IV 
communication  servers  (the  DECnet  Router,  the  DECnet  Router/X.25  Gate- 
way, and  the  Terminal  Server).  Event  logging  records  operational  events  such 
as  a  line  starting  up  or  shutting  down.  DECnet-RT  does  not  support  event 
logging. 

DECnet  uses  counters  to  track  other  kinds  of  events  and  errors.  A  system 
manager  can  periodically  record  these  counters  in  a  file  or  display  them  at  a 
terminal  to  obtain  detailed  statistics  on  the  node's  network  activity.  Node 
counters  maintain  statistics  on  logical  link  operations  —  for  example,  how 
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many  connect  requests  havr  t>een  sent  and  how  many  received  and  how  many 
messages  have  been  sent  over  logical  links  and  how  many  received.  In  Phase 
III  and  Phase  IV  implementations,  counters  record  Routing  layer  activity  as 
well  —  for  example,  how  many  errors  of  different  kinds  have  been  found  in 
packet  headers  and  how  many  line  initialization  and  line  verification  failures 
have  occurred. 

Line  counters  monitor  events  on  individual  communication  lines.  By  periodi- 
cally checking  each  line's  counters,  a  system  manager  can  gauge  its  perform- 
ance and  watch  out  for  potential  line  problems.  Line  counters  record  statistics 
such  as  the  number  of  data  blocks  sent  and  received  successfully,  the  number 
of  blocks  received  with  errors  and  the  number  of  times  a  tributary  has  passed 
from  active  to  dead  state. 

After  counters  have  been  displayed  or  recorded  in  a  file,  NCP  commands  can 
be  issued  to  set  the  counters  to  zero.  In  this  way,  a  system  manager  can 
manipulate  the  time  span  that  the  counters  monitor.  For  example,  a  system 
manager  could  set  all  node  counters  to  zero  as  programmers  begin  to  test  a 
network  application.  At  the  end  of  the  test,  the  counters  could  be  examined  to 
see  how  the  application  affected  the  node's  performance. 

Chapter  11  discusses  some  tools  that  the  system  manager  can  use  in  testing 
network  components  and  in  monitoring  network  activity. 


10.7    Down-line  Loading 


DECnet-VAX.  DECnet-RSX.  DECnet-IAS,  and  DECnet-2()  support  down- 
line loading,  which  means  loading  a  memory  or  system  image  from  a  file  at 
one  node  to  a  separate  target  node.  The  target  node  is  usually  an  RSX-llS 
DECnet  node  or  a  communication  ser\er  node  (DECnet  Router,  DE'^net 
Router/X.25  Gateway,  or  Terminal  Server.  These  are  memory-only  systems 
with  no  disk-based  file  storage  of  their  own. 

NOTE 

A  DECnet-2()  node  loads  a  system  image  down-line  to  a  speci- 
ally adapted  RSX-llS  node  called  a  DN2{X),  which  supports  a 
card  reader  and  a  line  printer  and  which  serves  as  a  remote 
batch  station.  The  DN20.  a  communications  front-end,  is 
loaded  in  the  same  way. 

At  a  DECnet-VAX,  DECnet-RSX-llM  or  M-PLUS  node,  the  system  mana- 
ger generates  the  target  system  image.  Once  generated,  the  image  can  be 
modified  by  VNP  commands  at  an  executor  node.  The  load  itself  can  be 
initiated  in  one  of  two  ways.  An  operator  can  issue  NCP  commands  to  load 
the  image  down-line  to  the  target  node,  or  an  operator  at  the  target  can 
initiate  the  load  by  triggering  a  bootstrap  ROM  (read-only  memory).  (Section 
10.7.3  explains  these  procedures.) 

Up-line  dumping  is  a  function  that  complements  down-line  loading.  This 
capability  is  described  in  Section  11.1.3. 
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10.7.1  Down-line  Loading  Definitions 

The  down-line  loading  function  is  distributed  among  two  or  more  nodes  in  a 
DECnet  configuration.  The  following  definitions  clarify  the  roles  played  by 
the  various  nodes. 

•  The  command  node  is  the  node  from  which  the  NCP  load  commands  are 
issued. 

•  The  executor  node  actually  executes  the  NCP  commands;  it  must  be 
adjacent  to  the  target  node. 

•  The  target  node  receives  the  system  image  loaded  down  the  line  or  dumps 
a  system  image  up  the  line  (see  Section  11.1.3). 

A  single  node  can  act  as  both  the  command  and  the  executor  node. 

10.7.2  Down-iine  Loading  Data  Base  Parameters 

For  every  target  node  to  be  down-line  loaded,  the  executor  has  access  to  a 
permanent  data  base.  Each  data  base  contains  default  parameters,  such  as 
node  verification  passwords  and  other  account  information,  for  down-line 
loading  a  specific  target  node.  The  system  manager  can  override  these  de- 
faults by  providing  parameter  values  in  an  NCP  LOAD  command.  The 
parameters  are  defined  initially  at  network  generation  and  can  be  redefined 
when  necessary. 

10.7.3  Performing  a  Down-line  Load 

Whether  a  remote  command  node  or  the  target  itself  initiates  the  load,  the 
target  must  have  local  access  to  a  cooperating  program  called  a  primary 
loader.  This  loader  is  usually  contained  in  a  bootstrap  ROM  (read-only  mem- 
ory) incorporated  in  the  target.  During  the  dowii-line  load  procedure,  a  series 
of  programs  can  be  loaded  on  top  of  the  primary  loader.  Each  program  calls 
the  next  until  the  system  image  itself  is  loaded  down-line. 

The  line  or  circuit  between  the  executor  and  the  target  is  in  a  TERVICE  state 
during  the  procedure  (see  Section  10.5.2).  Either  the  system  manager  expli- 
citly sets  the  state  to  SERVICE  or  the  DECnet  software  sets  the  state  auto- 
matically.  How  the  state  is  set  depends  on  the  implementation  and  on  the 
way  a  load  is  initiated. 

10.7.3.1  The  LOAD  Command  —  The  NCP  LOAD  command  is  the  means  of 
initiating  a  down-line  load  from  a  remote  command  node,  as  soon  as  the 
LOAD  command  has  been  issued,  an  operator  at  the  target  must  manually 
trigger  the  bootstrap  ROM  unless  the  service  line's  device  controller  is  a 
DMCU  or  DMRll  device.  These  devices  can  trigger  the  target's  primary 
loader  automatically  if  the  LOAD  command  passes  down  the  correct  password 
(see  Section  10.7.2).  Figure  10-2  illustrates  a  down-line  load  initiated  by  a 
command  node. 
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Figure  10-2:    Down-line  Load  Initiated  by  a  Command  Node 


10.7.3.2  Target-Initiated  Down-line  Loads  —  An  operator  at  the  target  node 
can  request  a  load  by  manually  triggering  the  primary  loader.  In  addition,  the 
loader  is  triggered  automatically  at  the  completion  ol  an  up-line  dump  from 
the  target.  Target -initiated  down-line  loads  always  use  the  parameter  values 
defined  in  the  permanent  data  base  for  the  target.  Figure  10  3  illustrates  a 
target-initiated  down-line  load. 

10.7.4    Down-line  Loading  and  Checkpointing  RSX-11S  Tasks 

D^rnet-llM.DECnet-llM-PLrS.  and  DKCnet  VAX  support  two  capabili- 
ties relating  to  a  DECnet-llS  node.  The  Hrst  is  called  down-line  task  loading. 
RSX-llS  tasks  can  be  stored  at  a  DECnet-llM.  DKCnet  DM  FLl'S.  or 
DECnet-VAX  node  and  loaded  to  the  RSX-llS  node.  The  second  is  called 
checkpointing,  which  is  a  standard  RSX-llM  capability.  An  executing 
RSX-llS  task  can  be  interrupted,  copied  in  its  interrupted  state  up  the  line, 
and  then  be  replaced  by  a  higher  priority  task  loaded  down-line  from  the 
execL  Of.  When  the  higher  priority  task  has  completed,  the  interrupted  task  is 
reloaded  down-line  and  allowed  to  continue  executing. 
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At  a  DECnet-UM  or  DFlCnet  llM-FIA'S  node,  the  operating  system  regu- 
larly checkpoints  tasks  to  local  disk  storage.  However.  RSX  IIS  nodes  are 
basically  memory-only  systems,  so  the  only  way  to  checkpoint  tasks  is  to  use 
the  executor's  disk  storage. 

These  two  capabilities  give  tlexibility  to  an  RSX-llS  node  that  would  not  be 
possible  without  DECnet.  To  change  the  set  of  resident  tasks  at  a  stand-alone 
RSX-llS  system,  an  operator  would  have  to  reboot  with  a  different  system 
image.  See  the  DECncl-HSX  System  Mcifiauvr's  (iuidc  and  the  l)K(- 
net-VAX  Sxsicm  Mananrr's  (iuidc  for  further  information. 
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Figure  10-3:    Down-tine  Load  initiated  by  a  Target  Noo 
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Chapter  11 

Monitoring  and  Testing  DECnet  Performance 
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Computer  networking  creates  a  highly  dynamic  environment.  Applications 
and  other  processes  are  exchanging  information  simultaneously  over  thou- 
sands of  circuits;  functions  at  various  levels  are  being  er  bled/disabled;  the 
status  of  network  components  is  changing  rapidly;  internetwork  communica- 
tions can  be  making  multiple  demands  for  protocol  handling;  warning  condi- 
ticms  can  arise  and  fatal  events  occur  in  different  regions  of  the  network  and  at 
various  levels  of  network  functi(m.  And  as  the  number  of  nodes  increases,  so 
does  the  volume  and  complexity  of  activity. 

Maintaining  a  high  level  of  network  availability  under  such  conditions  is  a 
challenge  to  network  management.  The  network  manager  must  have  tools 
that  report  on,  diagnose,  and  correct  conditicms  that  could  cause  performance 
degradation  or  failures.  Facilities  must  also  be  available  for  monitoring  net- 
work operation  so  as  to  detect  conditions  that,  if  left  to  develop,  could  lead  to 
major  communications  problems. 

Several  software  tools,  both  integrated  into  DECnet  and  available  separately, 
are  designed  to  help  the  network  manager  in  these  assignments.  The  inte- 
grated testing  t(K)ls  perform  the  following  functions: 

•  Test  that  user-specified  nodes  are  communicating  properly  and  that  mes- 
sages move  over  specified  circuits  and  lines  without  being  corrupted 

•  Test  operation  (»f  X.25  and  SNA  Gateways  to  determine  whether  or  not 
protocols  are  being  handled  properly 

•  Trigger  memory  dumps  to  help  you  establish  the  cause  of  node  crashes 

The  separately  available  monitoring  tool  is  a  product  called  Observer.  Run- 
ning in  a  DKCnet-RSX  node,  this  product  alerts  you  to  incipient  network 
problems  and  also  gathers  performance  statistics  that  can  help  you  to  recon- 
figure and  fine  tune  the  network  for  optimal  performance.  Each  of  these  tools 
is  discussed  in  the  following  sections. 
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11.1    Integrated  Testing  Tools 

The  following  tools  are  integrated  components  of  most  DECnet  implementa- 
tions. In  other  words,  when  you  install  DECnet,  these  testing  capahilities  are 
available. 

•  Loopback  testing 

•  Trace  capability 

•  L'p-line  dump 


11.1.1    Loopback  Testing 

U)opback  tests  exercise  software  and  hardware  by  repeatedly  sending  data 
through  a  number  of  network  components  and  then  returning  the  data  to  its 
source.  Figure  11-1  illustrates  the  hardware  points  from  which  test  data  may 
be  looped  back  lo  the  point  of  origin.  If  a  test  completes  successfully,  the  data 
loops  back  to  its  source  uncorrupted;  if  a  test  fails,  the  data  either  does  not 
return  to  its  source  or  returns  in  a  corrupted  state. 
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Figure  11-1:    Hardware  Loopback  Devices 
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A  system  manager  can  run  variations  of  the  loopback  tests  to  help  isolate 
network  components  responsible  for  losing  or  corrupting  data.  Digital  software 
services  personnel  routinely  run  loopback  tests  after  installing  DECnet  soft- 
ware. Successful  tests  verify  that  both  the  software  modules  and  the  hardware 
equipment  of  the  path  tested  are  operating  correctly. 

The  loopback-testing  capability  is  exercised  through  the  NCP  LOOPBACK 
command  in  combination  with  other  NCP  commands.  Loopback  enables  you 
to  check  whether  or  not  logical  links  are  properly  established  between  nodes, 
whether  or  not  DECnet  protocols  operate  properly  within  and  between  nodes, 
and  whether  or  not  messages  are  being  transmitted  properly  over  the  circuits 
and  lines  that  you  specify. 

Figures  11-2  and  11-3  show  the  NCP  commands  used  in  conjunction  with 
command-  and  program-initiated  node-level  loopback  tests,  respectively.  Fig- 
ure 11-4  shows  the  NCP  commands  used  in  conjunction  with  line  and  circuit 
level  loopback  testing. 

Test  data  is  transmitted  from  a  source  node  to  a  local  modem,  a  point  on  a 
line  connecting  two  nodes,  a  remote  modem,  or  to  a  remote  node  and  looped 
back  to  the  source  node.  Test  results  that  are  printed  out  indicate  whether  or 
not  the  target  network  component  that  you  specified  (line,  circuit,  or  node) 
tested  out  successfully.  Test  messages  specify  the  nature  of  an  error  condition 
that  may  have  cau.sed  the  test  to  complete  unsuccessfully. 

Loopback  testing  can  be  performed  for  general  purpose  nodes  and  communi- 
cations servers  over  Ethernet,  DDCMP,  SNA,  or  X.25  circuits. 

Used  in  combination,  loopback  testing  of  b(»th  nodes  and  circuits  can  help  you 
isolate  problem  areas  in  the  network.  Procedures  to  be  observed  for  each  of  the 
loopback  tests  are  specified  in  the  documentation  of  each  DECnet  product. 

11.1.2   Trace  Capability 

The  trace  capability  is  useful  in  defining  protocol  problems  that  may  arise  in 
the  gateway  products  that  handle  internetwc»rk  communication,  and  in  the 
PSI  (Packetnet  System  Interface)  products  that  enable  nodes  and  non-DEC- 
net  Digital  systems  to  communicate  over  PPSNs.  For  the  DECnet 
Router/X.25  Gateway,  the  trace  capability  is  exercised  by  means  of  the  NCP 
TRACE  command;  for  the  DECnet/SNA  Gateway,  the  trace  capability  is 
exercised  by  means  of  the  SNATRACE  utility.  These  capabilities  enable  you 
to  capture  and  analyze  those  portions  of  messages  that  define  how  protocols 
are  being  handled. 

Protocol  processing  by  the  DECnet  Router/X.25  Gateway  can  be  TRACEed  at 
levels  2  and  3  of  the  protocol-handling  software.  Level  2  defines  the  link  access 
procedure  for  data  exchange  between  computers  and  the  data  communica- 
tions equipment  that  establishes,  maintains,  and  terminates  communications 
between  computers  over  a  PSN.  The  level  3  protocol  defines  the  procedures 
for  formatting  and  exchanging  packets  transmitted  over  a  PSN. 
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Figure  11-2:    Command-initiated  Loopback  Tests 
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Figure  11^:    Line/Circuit  Level  Loopback  Tests 
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SNA  TRACK,  used  l<»r  identitvin^  protocol  prohlenis  that  can  arise  in  iisiii^' 
the  DKCiiet  SNA  (latewaw  enahles  y(»u  to  examine  protocol  handling'  at  the 
SDLC  lircuit  level,  the  j)hysiial  unit  level,  and  the  session  level.  At  the  SDI.C 
circuit  level,  you  retrieve  messages  on  a  specitied  circuit  as  thev  pass  between 
the  SDKC  module  and  the  device  driver  in  the  (iateway  node.  .At  the  physical 
unit  level,  you  retrieve  messajies  handled  hv  a  specified  phvsical  unit  as  thev 
pass  between  the  SN.A  module  and  the  SDLC  module  ot  the  (Iateway  .At  the 
session  level,  vou  retrieve  messages  being  exchanged  within  a  specitied  se.ssion 
as  they  pass  between  the  SN.A  and  SDLC  modules  ol  the  (Iateway. 

Documentation  for  each  of  the  Catevvay  products  tells  vou  how  t<»  use  these 
tacilities. 


11.1.3    Up-line  Dump 

Certain  nilernocie  relationshi{)s  \n  DKCnet  are  characterized  by  the  terms 
■"executor"  and  "'target.'"  .An  execut(»r  i.  >de  is  one  that  executes  NCf  com- 
mands that  altect  adjacent  target  node->.  Insofar  as  discussion  of  the  uphne 
dumj)  ca})abilitv  is  concerned,  a  target  node  is  either  a  DKCnet  RSX  ll.S 
node,  or  a  communications  server  node.  The  executor  n<tde  in  both  these  cases 
is  usuall\  the  one  from  wh.ich  the  target  node's  svstem  was  down-line  loaded, 
or  a  backup  node  ot  similar  (apabilit\  m  the  event  that  the  original  executor 
is  not  available. 

The  upline  dump  capability  enables  a  target  node  to  automat  icallv  initiate  a 
mem.orv  dump  up-line  to  the  executor  node  'Ibis  will  occur  when  the  target 
(»de  ser.^es  an  impending  system  crash.  Hv  analyzing  the  memors   dump. 
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In  order  to  keep  the  target  node  available  to  the  network,  the  executor  node 
will  automaticallv  down-line  load  the  .'arget's  system  upon  completion  of  the 
dump.  Detailed  descriptions  of  the  DKCnet  facilities  that  operate  in  upline 
flumping  and  of  the  .NCI*  commands  to  be  used  to  assur"  that  lim's  and 
circuits  specified  in  the  procedure  can  a(commodate  the  dump  are  presented 
in  the  d(Humentation  of  the  systems  in  which  the  capability  resides. 

An  upline  dump  can  also  be  triggered  by  the  system  manager  at  the  executor 
node  at  anv  time,  or  can  be  done  automaticallv  if  the  remote  svstem  crashes. 


11.2    Monitoring  Network  Operation  with  Observer 

Observer  is  a  software  product  that  monitors  the  performance  of  DKCnet 
networks.  Installed  in  a  Phase  Ili  or  Phase  I\'  DKCnet  KSX  node,  it  gathers, 
processes,  and  generates  information  on  network  performance.  Network 
events  such  as  changes  in  line.  link,  and  node  states  are  displayed  as  they 
occur  on  a  VTl(M)  terminal  dedicated  to  this  function:  other  information  is 
logged  to  files  that  can  be  processed  periodically  to  produce  network  perform- 
ance reports.  A  command  terminal  that  offers  you  a  menu-based  approach  to 
network  surveillance  enables  you  to  display  a  broad  range  of  information 
concerning  the  state  ut  designated  network  components,  \'u\  can,  for  exam- 
ple retrieve  statistical  information  regarding  network  operation  and  also  en- 
ter lommands  affecting  the  reporting  relationship  between  Observer  and 
specified  network  components  or  regions. 
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The  information  that  appears  on  the  event  display  terminal  can  alert  you  to 
conditions  that  might  cause  problems  in  network  operation.  Forewarned,  you 
can  then  take  steps  to  correct  such  conditions  before  major  communications 
or  performance  problems  develop.  If,  for  example,  a  message  from  Observer 
notifies  you  of  high  data  traffic  over  a  specific  link,  it  might  mean  that  certain 
nodes  are  processing  and  transmitting  unexpected  data  loads  or  that  you 
originally  specified  too  low  a  data  rate  for  that  link.  Proper  action,  through 
Observer  facilities,  in  respect  to  the  nodes  and  the  link  could  then  improve 
performance  in  that  part  of  the  network. 

By  means  of  a  menu-based  approach  as  shown  in  Figures  11-5,  11-6,  and 
11-7,  the  command  terminal  enables  you  to  monitor  more  closely,  specific 
regions  and  components  of  the  network  and  to  control  Observer  operation. 

Figures  11-5,  11-6,  and  11-7  illustrate  just  one  example  of  how  you  can  use 
Observer  to  focus  in  on  various  network  areas  and  components.  Figure  11-5 
illustrates  the  Master  Menu  that  appears  on  the  command  terminal.  If  you 
select  "A"  from  this  menu,  for  example,  the  Network  Summary  Status  Dis- 
play (Figure  11-6)  appears.  This  screen,  which  is  updated  about  every  'M) 
seconds,  displays  summary  information  concerning  the  network  being  moni- 
tored. In  addition  to  presenting  identification  information,  it  specifies  the 
number  of  nodes  reachable  and  unreachable  from  the  Observer  node,  the 
results  Observer  obtained,  and  other  statistics  gleaned  in  the  most  recent 
polling  cycles.  The  names  of  the  nodes  in  the  network  or  network  regions  are 
also  displayed.  Network  regions  are  user-defined.  Analysis  of  the  information 
logged  by  Observer  can  serve  as  a  basis  for  reconfiguring  the  network  and 
tuning  it  for  optimum  performance. 
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Figure  11-5:    Observer  Master  Menu 
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Figure  11-6:    Observer  Summary  Status  Display 
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Figure  11-7:    Observer  Node  Detail  Display 
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To  focus  in  further,  you  can  summon  up  a  Node  Detail  Display  (Figure  11-7) 
for  a  particular  node.  As  shown  in  the  illustration,  this  screen  displays  certain 
status  information  concerning  the  node  selected.  If  you  need  still  further 
information  in  order  to  diagnose  a  problem,  you  can  select  another  display 
directly  or  go  back  to  the  Summary  Status  display.  Detailed  information  on 
the  ease  with  which  Observer  enables  you  to  move  from  one  screen  to  another 
is  contained  in  the  Observer  User's  Guide. 

Observer  monitors  nodes,  links,  end-to-end  traffic,  and  network  regions.  It 
reports  three  kinds  of  information: 

•  State  information 

•  Status  information 

•  Statistics 

State  and  status  information  are  identified  in  Table  11-1.  The  kinds  of  statis- 
tics gathered  and  maintained  by  Observer  are  listed  in  Table  11-2.  See  Ob- 
server documentation  for  details  on  function,  installation,  and  operation  of 
the  product. 

Table  11-1:    Observer-maintained  State  and  Status  information 


0 


Element 

State/Status 

Link 

Link  error  rate  status 

Link  traffic  rate  status 

Link  real-time  event -logging 
status 

Link  state 

Node 


Region 


Base  system  and  end  traffic 
enable  status 

Node  data  acquisition  status 

Node  traffic  rate  status 

Node  real-time  event-logging 
status 

Node  state 

Base  system  and  end  traffic 
enable  status 

Node  reachability  check  com- 
pletion status 

Base  system  and  end  traffic 
polling  cycle  completion 
status 


Pottibit  Conditions 

Normal/Degrading/Degraded/Unusable 

Normal/High/Low 

Enabled/Disabled 

Initialization/On  Line/Unknown/Removed 
Enabled/Disabled 

Unreachable/Normal/Unknown/Error 

Normal/High/Low 

Enabled/Disabled 

Initialization/NormalAVarning/Fatal  Error 
Enabled/Disabled 

Initialization/NormalAVarning/Fatal  Error 

Initialization/Normal/Warninft/Fatal  Error 
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Table  11-2:    Statistics  Maintained  by  Observer 


Typ«  of  statistic         Elsmtnt 

Time  related  Node 

Link 


Error  related 


Node 


Link 


Traffic  related 


Node 


Link 


Statistics 

Time  base  in  seconds 
Time  last  data  received 
Time  of  last  state 

Time  base  in  seconds 

Time  last  data  received 

Time  of  last  state  change  to  on 

Buffer  resource  errors 
Packet  format  errors 
Partial  routing  update  loss 
Aged  packet  loss 
Node  unreachable  packet  loss 
Out -of- range  packet  loss 
Oversize  packet  loss 
Network  errors 
Node  errors 

Data  blocks  sent 

Data  blocks  received 

Collision  detect  check 

Failure  (Ethernet  only) 

Data  errt)rs  nutbound 

Local  reply  timeouts 

Data  errors  inbound 

Local  buffer  errors 

Unknown  fra.ne  destination  (Ethernet  only) 

Congestion  loss 

Selection  timeouts 

Resets 

Link  error  level 

Link  down 

Bytes  received 

Bytes  sent 

Node  traffic  level  (bytes) 

Packets  received 

Packets  sent 

Node  traffic  level  (packets) 

Link  traffic  level  (bytes) 

Link  traffic  level  (packets) 

Bytes  sent 

Data  blocks  sent 

Data  blocks  received 

Transit  packets  sent 

Originating  packets  sent 

Blocks  deferred  (Ethernet  only) 

Blocks  sent  with  collision  (Ethernet  only) 

Bytes  received 

Transit  packets  received 

Terminating  packets  received 

Multicast  blocks  received  (Ethernet  only) 
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